debugging a crash on Windows
Lubomir I. Ivanov
neolit123 at gmail.com
Sun Jun 8 10:48:49 PDT 2014
On 7 June 2014 18:02, Dirk Hohndel <dirk at hohndel.org> wrote:
> Can other people reproduce the crash with the attached xml file?
> Lubomir, when you build natively, do you see this as well?
sorry, i was out of town.
i can't get it to crash with the test file and the native windows build:
Qt version 5.3.0 (pre-ecompiled installer download)
gcc version 4.8.2 (bundled with the above)
a very recent marble from git / master (75a354ba75b)
not-so recent libgit2 (64a862c2b)
if there is no useful stack trace you can start adding "markers" such
as, puts("marker 1"); puts("marker 2") at key locations and see which
one is reached. this is slow, but will narrow down the troubling call.
to enable the console add "CONFIG += console".
gdb usually works for me, but not always. for example Qt asserts are
annoying, because if a Qt func. in a library asserts somewhere i don't
know how to backtrace and i use the above method. could be just me.
another thing you can do is to get the crash offset and disassemble:
e.g. on windows 7 -> right click the my computer icon -> manage ->
event viewer -> windows logs -> applications.
should be a new "error" entry after a crash.
grab the "fault offset"
here is a simulated crash by adding:
*((unsigned int*)0) = 0xDEAD;
reported fault offset: 0000e6cc
this means 0x0040e6cc as a runtime offset (and for i386).
use --start-address and some --stop-address after it.
-l should add source file line numbers if compiled with debug symbols (-g)
objdump --start-address=0x40e6cc --stop-address=0x40e6dd -l -D subsurface.exe
subsurface.exe: file format pei-i386
Disassembly of section .text:
40e6cc: c7 00 ad de 00 00 movl $0xdead,(%eax)
<----------------- here is our SIGSEGV; EAX probably 0 at that point
40e6d2: e8 89 ce 0c 00 call 4db560 <_git_threads_init>
40e6d7: e8 d4 a7 06 00 call 478eb0 <_setup_system_prefs>
40e6dc: ba c0 0e 5f 00 mov $0x5f0ec0,%edx
More information about the subsurface