Debugging in the Cygwin environment

Ah, the joy of debugging. There is nothing quite like spending time unsuccessfully trying to track down a problem in someone else's source code. </sarcasm>

Right... What really makes it bad is when you can't even avail of the set of tools that you've grown accustomed to from working in a Unix environment.

Working in Cygwin is certainly more pleasant than working in a vanilla Windows environment, but it doesn't afford quite the same power and flexibility of working in a native Unix environment.

Last night I was trapped in a debugging session, trying to pinpoint an obscure segmentation fault which only occurs on some Windows test boxes.

When a process (i.e. foo.exe) cores, a default stackdump foo.exe.stackdump is generated. This stackdump contains (among other things) stack frames and functions addresses. You can make some sense of it by using the `addr2line' utility, but it's not as convenient as using a debugger.

Which takes me to the actual useful bit on information in this post. You can instruct Cygwin to start your gdb debugger just in time when an fault occurs or have Cygwin generate a real core dump.

To achieve this, add `error_start=action' to the Cygwin environment variable:

# start gdb
export CYGWIN="$CYGWIN error_start=gdb -nw %1 %2"

# generate core dump
export CYGWIN="$CYGWIN error_start=dumper -d %1 %2"

You might have to use a full Windows-style path to gdb and dumper if the directory they live in is not in the system-wide PATH.

More information is available in the info and man documentation in Cygwin. Check out dumper's man page and Cygwin's man page, in particular the bit regarding the CYGWIN environment variable.

One final note, I haven't had much luck with dumper. It seems a bit temperamental. Your mileage may vary.