How to debug fatal exceptions on Windows?

How to debug fatal exceptions on Windows?

[Eli Zaretskii]

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

RE: How to debug fatal exceptions on Windows?

[Pierre Muller]

  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

Re: How to debug fatal exceptions on Windows?

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Date: Tue, 6 Aug 2013 17:45:36 +0200
> 
>   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?

If I do that, and the breakpoint breaks, how will I be able to see
which code in the application (Emacs) caused the exception?

Or did you mean something else?

Thanks.

Re: How to debug fatal exceptions on Windows?

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Date: Tue, 6 Aug 2013 17:45:36 +0200
> 
>   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.

That is true, but it is unrelated to the issue I was having.  In the
use case I described, GDB was attached to Emacs when Windows already
displayed the "application needs to close" dialog.  At that point, the
search for exception handler already found the _gnu_exception_handler
function installed by the MinGW startup code, and called it.  The
problem is that the call stack down to the place that caused the
exception is not visible to GDB at this point.

So I think the possibility of GDB seeing an unknown exception on the
first chance call is not the problem here.

Re: How to debug fatal exceptions on Windows?

[Paweł Sikora]

On Tuesday 06 of August 2013 18:34:03 Eli Zaretskii wrote:
> 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?

from the winapi level you can use AddVectoredExceptionHandler (winapi) to install custom exception filter
at the first position in the chain. next, from the exception filter you can examine suitable ExceptionRecord->ExceptionCode,
and examine ContextRecord for more details.

the easier way is to use http://code.google.com/p/backtrace-mingw/

BR,
Paweł.

-- 
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

Re: How to debug fatal exceptions on Windows?

[Eli Zaretskii]

> From: Paweł Sikora <pawel.sikora@agmk.net>
> Date: Tue, 06 Aug 2013 20:49:54 +0200
> 
> from the winapi level you can use AddVectoredExceptionHandler (winapi) to install custom exception filter
> at the first position in the chain. next, from the exception filter you can examine suitable ExceptionRecord->ExceptionCode,
> and examine ContextRecord for more details.
> 
> the easier way is to use http://code.google.com/p/backtrace-mingw/

Thanks, I will study these.  Emacs already have a backtrace facility,
so I guess only the exception analysis stuff needs to be upgraded.