This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb coredumps on any executable

Igor Peshansky wrote:

> Ping.  Did this get overlooked?  Can people at least confirm that this
> works for them on the same setup, so I can start looking for a problem in
> my local installation?

Yes, it does work fine here.  I don't know if there's anything
noteworthy about my setup, although I am using a self-built Cygwin DLL
from fresh vintage, but I'm quite sure that I never saw this when using
a stock release either.  I tried from both a pty and a windows console,
that didn't make a difference.

One suggestion if you want to try debugging this is that if you build
gdb from source and run it from its build dir (where it creates a
.gdbinit) it has special support for debugging itself, i.e. gdb inside
gdb.  That of course assumes that the version you build doesn't also

Another suggestion that can work would be to set error_start to a native
debugger such as windbg.exe or (my favorite) OllyDbg.  The error_start
method puts the PID on the command line and I think both of those
debuggers can accept a PID as parameter, but you might have to also
supply an argument/flag.  I forget the details here but I seem to recall
that I got it working at one point.  At any rate, you'll at least get a
picture of the stack and a disassembly of the faulting location, but
none of the debugging symbols will be of any use as the native debuggers
all grok PDB and not stabs.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]