Bug 15868 - backtrace interfaces and calls to noreturn functions
Summary: backtrace interfaces and calls to noreturn functions
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: 2013-08-20 20:13 UTC by Joseph Myers
Modified: 2019-08-21 12:07 UTC (History)
2 users (show)

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


Attachments
Testcase (1.35 KB, text/x-csrc)
2013-08-20 20:13 UTC, Joseph Myers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Myers 2013-08-20 20:13:40 UTC
Created attachment 7155 [details]
Testcase

The backtrace / backtrace_symbols / backtrace_symbols_fd interfaces do not work well when backtracing through calls to noreturn functions (a natural use case - a noreturn error-handling function might reasonably wish to print a backtrace).

This is illustrated by the attached testcase on x86_64.  At least with some GCC versions, the call to a noreturn function has return address pointing to padding after the end of the calling function, meaning that it does not point inside that function and so a name for it cannot be found.

The backtrace interface is that the addresses are return addresses.  But reliable backtracing requires additional information about whether frames are signal frame, in which case the return address points inside the relevant function, or not, in which case you should subtract 1 to be sure of being inside the relevant function.  (That involves calling _Unwind_GetIPInfo instead of _Unwind_GetIP to get the relevant information.)  So to support this case reliably, there should be new interfaces that handle this adjustment in some way.

(Old discussion started at: http://www.eglibc.org/archives/patches/msg01077.html .)
Comment 1 Jonny Grant 2019-03-30 23:07:48 UTC
I saw -O1 also stops backtrace_symbols

https://sourceware.org/bugzilla/show_bug.cgi?id=24401