RE: How to debug fatal exceptions on Windows?

["Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>]

  Hi Eli,


  I could be that some "special" exception code is 
used that is not understood by GDB.
  In fact, an exception is send first to the debugger,
then to the debuggee, and lastly again to the debugger if not handled by the
debuggee.

  But if GDB does not recognize the exception code,
it dies nothing on the first pass. 
And the code is then caught by the gnu_exception_handler.

  
  Did you try to run gdb on itself and
place a breakpoint on the location of the FirstChance code?

in windows-nat.c:

1231-      DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_NONCONTINUABLE_EXCEPTION");
1232-      ourstatus->value.sig = GDB_SIGNAL_ILL;
1233-      break;
1234-    default:
1235-      /* Treat unhandled first chance exceptions specially.  */
1236:      if (current_event.u.Exception.dwFirstChance)
1237-   return -1;
1238-      printf_unfiltered ("gdb: unknown target exception 0x%08x at
%s\n",
1239-   (unsigned) current_event.u.Exception.ExceptionRecord.ExceptionCode,
1240-   host_address_to_string (
1241-     current_event.u.Exception.ExceptionRecord.ExceptionAddress));

Or you could simply check what happens if you put the lines 12361237 after
the printf_unfiltered call.

  I had occasions where this helped...
Hoping it will also be helpful here.

Pierre Muller

> -----Message d'origine-----
> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la part
> de Eli Zaretskii
> Envoyé : mardi 6 août 2013 17:34
> À : gdb@sourceware.org
> Objet : How to debug fatal exceptions on Windows?
> 
> I need the help of the wizards here, thanks in advance.
> 
> For some time now people who track Emacs development on Windows (using
> MinGW) report crashes that seem like some fatal exception that is
> caught by the top-level exception handler installed by the MinGW
> startup code.  Here's a recent example with the backtrace:
> 
>   #0  0x75639bfd in KERNELBASE!DebugBreak () from
> /cygdrive/c/Windows/SYSTEM32/KERNELBASE.dll
>   #1  0x01156c53 in emacs_abort () at w32fns.c:7717
>   #2  0x0100145d in terminate_due_to_signal (sig=11, backtrace_limit=40)
at
> emacs.c:344
>   #3  0x011472bb in handle_fatal_signal (sig=11) at sysdep.c:1638
>   #4  0x01147296 in deliver_thread_signal (sig=11, handler=0x11472a2
> <handle_fatal_signal>) at sysdep.c:1614
>   #5  0x011472ef in deliver_fatal_thread_signal (sig=11) at sysdep.c:1650
>   #6  0x010011ea in _gnu_exception_handler@4 ()
>   #7  0x7564084e in UnhandledExceptionFilter () from
> /cygdrive/c/Windows/SYSTEM32/KERNELBASE.dll
>   #8  0x008867a4 in ?? ()
>   #9  0x775fbf2c in ntdll!RtlCreateUserThread () from
> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
>   #10 0x775dbf0c in ntdll!RtlInitializeExceptionChain () from
> /cygdrive/c/Windows/SYSTEM32/ntdll.dll
>   #11 0x00000000 in ?? ()
> 
> gnu_exception_handler is the handler installed by startup.
> 
> The problem is that given this information it is impossible to say
> which code triggered the problem (or at least I don't know how), and
> thus the problem, whatever it is, goes unsolved.
> 
> Could someone suggest techniques for how to dig deeper into such
> problems in order to find out which application code causes this?  If
> additional diagnostic code should be added to Emacs, that is OK, as
> long as that additional code can be in the application, not in the
> startup code.
> 
> TIA