backtrace() returns only one stack frame on Jetson TX1

Hi,

I’m trying to debug my application for some issue using backtrace()http://man7.org/linux/man-pages/man3/backtrace_symbols.3.html function. On other linux platforms this works fine. But on Jetson TX1 only one stack frame is returned.

I tried the sample code mentioned in the link above. I get the following output
./stacktrace 3
backtrace() returned 1 addresses
./stacktrace() [0x40096c]

Whereas it is supposed to output
./stacktrace 3
backtrace() returned 8 addresses
./stacktrace() [0x4007a3]
./stacktrace() [0x400834]
./stacktrace() [0x40085b]
./stacktrace() [0x400854]
./stacktrace() [0x400854]
./stacktrace() [0x4008b9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f5616f6976d]
./stacktrace() [0x4006c9]

Does anyone know any solution for this?

I’ve not looked at this, but typically such strangeness would be either from stack corruption or optimizing. Was there any optimization going on?

The code is as simple as this -

#include <execinfo.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define BT_BUF_SIZE 100

void myfunc3(void)
{
   int j, nptrs;
   void *buffer[BT_BUF_SIZE];
   char **strings;

   nptrs = backtrace(buffer, BT_BUF_SIZE);
   printf("backtrace() returned %d addresses\n", nptrs);

   /* The call backtrace_symbols_fd(buffer, nptrs, STDOUT_FILENO)
	  would produce similar output to the following: */

   strings = backtrace_symbols(buffer, nptrs);
   if (strings == NULL) {
	   perror("backtrace_symbols");
	   exit(EXIT_FAILURE);
   }

   for (j = 0; j < nptrs; j++)
	   printf("%s\n", strings[j]);

   free(strings);
}

void  
myfunc2(void)
{
   myfunc3();
}

void
myfunc(int ncalls)
{
   if (ncalls > 1)
	   myfunc(ncalls - 1);
   else
	   myfunc2();
}

int
main(int argc, char *argv[])
{
   if (argc != 2) {
	   fprintf(stderr, "%s num-calls\n", argv[0]);
	   exit(EXIT_FAILURE);
   }

   myfunc(atoi(argv[1]));

exit(EXIT_SUCCESS);
}

So I don’t suspect, stack corruption. Also the same code runs fine on other linux machines.

I used O0 optimization

Did you also use “-g”? Definitely “-O0” would be correct, but you’d still need debug symbols. If you have “-g”, then there may be some other limitation.

NOTE: If you can show the entire compile option list it may help, e.g., a build log for that particular file and the linking stage.

I’ve looked at this problem and found no improvement, even with -O0 -g (debug symbols would be useful for understanding the call stack, but addresses should be shown anyway) or no-omit-frame-pointers or other machine options.

Maybe you can try with an older version of gcc if you just want to debug a program, but this is just for trying, not sure at all it really helps.

Using -funwind-tables in gcc flags seems to fix this :

gcc -O0 -funwind-tables -otest_backtrace test_backtrace.c

./test_backtrace 3
backtrace() returned 7 addresses
./test_backtrace() [0x4009b0]
./test_backtrace() [0x400a78]
./test_backtrace() [0x400ab0]
./test_backtrace() [0x400aa8]
./test_backtrace() [0x400aa8]
./test_backtrace() [0x400b20]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe0) [0x7f9e0948a0]

I haven’t used this, but I found something which may be interesting for your case (I’d be curious if it improves your particular debug situation):

-fvar-tracking-assignments