On 24.08.2017 14:52, Jan Kratochvil wrote:
On Thu, 24 Aug 2017 14:31:11 +0200, Sandro Mani wrote:
On 24.08.2017 14:18, Jan Kratochvil wrote:
On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote:
I'm investigating why gdb returns so unreliable backtraces for mingw
binaries without debuginfos,
They are perfectly reliable. They just do not show the function names.
But those can be looked up later from *-debuginfo.rpm.
I regularly have the issue that with larger programs, gdb aborts with
"Backtrace stopped: previous frame inner to this frame (corrupt stack?) " if
the crash happens somewhere deep down, say in some Qt library, and never
gets to printing the frames of the caller of the application code I'm
interested in. If debugsymbols are available, it prints the all the frames.
Hence "unreliable". I supose this might be a bug, but I have no idea how to
investigate.
In your OP example:
: #0 0x000000000040157d in ?? ()
: #1 0x00000000004015b5 in ?? ()
: #2 0x00000000004013f7 in ?? ()
: #3 0x000000000040152b in ?? ()
: #4 0x0000000076af652d in KERNEL32!BaseThreadInitThunk ()
: from C:\Windows\system32\kernel32.dll
: #5 0x0000000076d2c521 in ntdll!RtlUserThreadStart ()
: from C:\Windows\SYSTEM32\ntdll.dll
: #6 0x0000000000000000 in ?? ()
: Backtrace stopped: previous frame inner to this frame (corrupt stack?)
:
: With strip-debug, gdb reports:
:
: #0 0x000000000040157d in foo() ()
: #1 0x00000000004015b5 in main ()
You can see the backtrace is the same. I guess you will see that
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
even with installed *-debuginfo.rpm after you enter:
(gdb) set backtrace past-main on
(gdb) set backtrace past-entry on
The symbols (particularly the "main" symbol) just tell GDB to stop backtracing
earlier. But the part that it already backtraced is the same.
In some cases *-debuginfo.rpm can really improve the backtrace (even the
numerical-only one, ignoring the address->functionname decoration).
This is due to .debug_frame sections there when the main binary is missing
corresponding .eh_frame. But I have no idea how this works in PE32 and then
it is a packaging bug (missing -fasynchronous-unwind-tables) as the
numerical-only backtraces should be the same with and without debuginfo.
Last difference can be due to inlined functions being shown just with
*-debuginfo.rpm but that is not much important (and reconstructable from the
numerical-only backtrace).
Thanks for your explanations. Actually I wonder if indeed fooled by the
"backtrace past-main on" thing. Next time I'll hit some cryptic
stacktrace I'll double check.
While I'm at it, my current technique for interpreting mingw stacktraces
produced without debuginfos is parsing the text and calling addr2line
for each stack frame. Is there a neater technique?
But these *-debuginfo.rpm differences will not happen with your planned bare
functionname symbols (called ELF symbols or PE32 symbols in your case).
I'll do a quick size-analysis of some common packages (say gtk, qt) and
if the size increase is not prohibitively large, I'll file a change to
have these symbols included by default in the mingw binaries. Beyond
possible stacktrace quality differences, I'm also interested in making
life more pleasant when one has to do live-debugging on without debuginfos.
Sandro
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
