Re: How to catch GDB crash

[Brian Dessent <brian@dessent.net>]

Pedro Alves wrote:

> for native Windows apps, there is some registry key (I don't
> remember which) you can set to point to a JIT debugger.  Probably

For the sake of the archives it's HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AeDebug, see <http://support.microsoft.com/kb/103861>.

> a little exe wrapper is needed to translate the incoming args
> to GDB args, that's all.

The first %ld in the command expands to the faulting PID so
"path-to\gdb.exe -p %ld" ought to work without need for a wrapper.

> I can't see what changes in GDB
> would be required?

The main problem is that gdb thinks that it's attaching to a normal
running process, rather than a faulted app.  Thus the current thread is
an artificial one with %eip in ntdll!DbgUiConnectToDbg which is just a
convenient 'int3' that lives in ntdll.dll as discussed.  That's easily
fixed just by switching to the thread of interest, however the state of
that thread often looks something bogus like this:

(gdb) bt
#0  0x7c90eb94 in ntdll!LdrAccessResource ()
   from C:\WINXP\system32\ntdll.dll
#1  0x7c90e9ab in ntdll!ZwWaitForMultipleObjects ()
   from C:\WINXP\system32\ntdll.dll
#2  0x7c86372c in UnhandledExceptionFilter ()
   from C:\WINXP\system32\kernel32.dll
#3  0x00000002 in ?? ()
#4  0x0022f560 in ?? ()
#5  0x00000001 in ?? ()
#6  0x00000001 in ?? ()
#7  0x00000000 in ?? ()

The actual location of the fault in the user code is nowhere evident (in
this testcase, it was at eip 00401304) because gdb doesn't know that it
has picked up in the middle of a fault.  You can get things back on
track by re-triggering the same fault again by continuing, but this
really isn't pretty and doesn't always work.  For this to work correctly
gdb would need some command line switch to tell it that it's taking over
a faulted process as the JIT, rather than breaking in on a normally
executing one.

Brian