Created attachment 7716 [details] c file to simulate the error. Hi, I am trying to generate a call stack trace using backtrace() API which is part of libbacktrace. The idea is to catch a SIGSEGV signal and call backtrace() to print all the address values and compare the obtained addresses from objdump -D of executable. Attached is a simplified version of the application. Following is the output seen on ARMv7a platform with buildroot cross-toolchain (gcc- 4.8.2, binutis-2.18.1). To compile the application: ${CROSS_COMPILE}gcc -o crash_test -O0 -funwind-tables -rdynamic crash_test.c ARMv7a# ./crash_test Trying to access NULL pointer! SIGSEGV Handler! Got Backtrace Size=2 0x00008724 0x000087c4 ARMv7a# The above function call trace is only that of the signal hander (print_back_trace, sigsegv_handler) and does not show the entire call stack for the function where program crashed (print_back_trace, sigsegv_handler, func2, main). On x86 host same program shows a deeper function call trace right up to the main function and even beyond: x86-RHEL5-host$./crash_test Trying to access NULL pointer! SIGSEGV Handler! Got Backtrace Size=7 0x00400939 0x004009ab 0x30930302f0 0x004009d3 0x00400a7b 0x309301d994 0x00400889 x86-RHEL5-host$ Can someone please comment on what is going wrong. Any special flags that need to be used while compiling/linking the program. http://lists.uclibc.org/pipermail/uclibc/2013-September/047932.html Similar issue in uclibc was solved by creating a patch to uclibc files, can some one let me know if there is any existing patch is available for glibc similar to this?, if not can anyone help me in providing the similar patch for glibc. Please let me know if i can provide any info. /Thanks Prafulla
First, you should make sure that the debug/tst-backtrace* tests pass when you run the glibc testsuite. Then, investigate how your test differs from those tests. Note that ARM EABI unwind info (as generated by GCC) does not fully support asynchronous unwinding even if you use -fasynchronous-unwind-tables.
Hi Joseph/All, Thanks for your inputs, I will verify the tests you suggested. Below links shows that patch is added for same issue in ulibc. I was wondering if there is a similar patch available for glibc as well. http://lists.uclibc.org/pipermail/uclibc/2013-September/047932.html We observed that stack trace is working fine after the patch in ulibc, We needed the same for glibc as well. Thanks, Prafulla
Hi All, Appreciate if somebody could provide the fix for backtrace for below issue as an example void func1() { int val; char buf[256]; val = 100; printf("\nTrying to construct invalid buffer!\n"); snprintf(buf, sizeof (buf), "%s", val); printf("The content of buf: %s\n", buf); } For other issues like NULL pointer access or invalid memory access, backtrace is working fine in glibc but not for above type of issues. For above issue uclibc forum has given fix in below link http://lists.uclibc.org/pipermail/uclibc/2013-September/047932.html I am looking for similar fix info or patch, so that i can make changes if someone points out relevant changes. Thanks, Prafulla Kota.
You are free to configure your compiler to default to -fasynchronous-unwind-tables if you want, or to build glibc with that option, but I don't think it's an appropriate default for glibc; it should be used in glibc only for specific files where asynchronous cancellation may occur. When you make invalid use of glibc - passing arguments to functions that result in undefined behavior - there is no guarantee that the stack is in an unwindable state when the segfault occurs (return addresses may have been overwritten as a result of the invalid arguments, for example).
Backtrace doesn't work for the same reason throwing exceptions from signal handlers doesn't work: glibc on ARM doesn't support unwinding through signal handlers. This is something for which I showed a standalone fix a while back [1], which also fixes backtrace [2]. It can serve as example for anyone feeling motivated to fix the problem in glibc itself. It does still require the code that causes the segfault to be compiled with -fnon-call-exceptions or -fasynchronous-unwind-tables. [1] https://gcc.gnu.org/ml/gcc/2015-10/msg00018.html [2] https://gcc.gnu.org/ml/gcc/2015-10/msg00022.html