26

So I wrote buggy code that occasionally crash ... and creates a stackdump file.

Using addr2line I can figure out how the program got to the crash point by decoding the addresses from the stackdump one by one. Is there an alternative tool that can ease the debug using stack dumps? Is there a way to to load this information in Insight/Gdb?

Gerhard
  • 6,850
  • 8
  • 51
  • 81

2 Answers2

50

You can instruct Cygwin to start your gdb debugger just in time when an fault occurs. To achieve this, add error_start=action to the Cygwin environment variable:
export CYGWIN="$CYGWIN error_start=gdb -nw %1 %2"

Else you can have Cygwin generate a real core dump.
export CYGWIN="$CYGWIN error_start=dumper -d %1 %2"

Gerhard
  • 6,850
  • 8
  • 51
  • 81
  • 3
    And run `gdb path/to/the/binary path/to/the/core` to debug it. Thanks to http://stackoverflow.com/a/5115653/204658. – thoni56 Feb 27 '16 at 13:59
  • With this option `error_start=gdb -nw %1 %2` enabled, I have gdb running, however quitting gdb just results it in starting again, how I quit it completely? – CMCDragonkai Jan 13 '17 at 07:04
  • I had to go outside and launch process explorer and kill the entire process tree in Windows. – CMCDragonkai Jan 13 '17 at 07:16
  • 2
    @CMCDragonkai For future reference you can just type "kill" in gdb to kill the debugged process and then "quit" to quit gdb as well. – Anonymous1847 Aug 10 '20 at 21:49
0

Firstly, make sure you build with source debugging enabled (the using -g option):

gcc -g -o myfile myfile.c

Then Load the dump into gdb after the crash (or insight, or ddd)

gdb myfile core
BenB
  • 10,300
  • 7
  • 32
  • 30