Bug 17176 - backtrace() not working on ARMv7a
Summary: backtrace() not working on ARMv7a
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.18
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-18 11:57 UTC by prafulla chandra kota
Modified: 2020-01-24 17:39 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
c file to simulate the error. (526 bytes, text/x-csrc)
2014-07-18 11:57 UTC, prafulla chandra kota
Details

Note You need to log in before you can comment on or make changes to this bug.
Description prafulla chandra kota 2014-07-18 11:57:53 UTC
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
Comment 1 jsm-csl@polyomino.org.uk 2014-07-18 15:51:01 UTC
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.
Comment 2 prafulla chandra kota 2014-07-22 10:21:33 UTC
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
Comment 3 prafulla chandra kota 2014-07-25 12:10:44 UTC
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.
Comment 4 jsm-csl@polyomino.org.uk 2014-07-25 15:21:13 UTC
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).
Comment 5 Matthijs van Duin 2020-01-24 17:39:31 UTC
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