backtrace() returns only one stack frame on Jetson TX1

Autonomous Machines Jetson & Embedded Systems Jetson TX1
1

Hi,

I’m trying to debug my application for some issue using backtrace()[url]http://man7.org/linux/man-pages/man3/backtrace_symbols.3.html[/url] 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?

2

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

3

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.

4

I used O0 optimization

5

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.

6

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.

7

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]
8

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