From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19886 invoked by alias); 6 Aug 2013 15:45:51 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 19827 invoked by uid 89); 6 Aug 2013 15:45:51 -0000 X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,MSGID_MULTIPLE_AT,RDNS_NONE autolearn=no version=3.3.1 Received: from Unknown (HELO mailhost.u-strasbg.fr) (130.79.201.41) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 06 Aug 2013 15:45:50 +0000 Received: from md16.u-strasbg.fr (md16.u-strasbg.fr [130.79.200.206]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r76FjdDi079365 ; Tue, 6 Aug 2013 17:45:39 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from ms13.u-strasbg.fr (ms13.u-strasbg.fr [130.79.204.113]) by md16.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r76FjdlD004740 ; Tue, 6 Aug 2013 17:45:39 +0200 (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (Authenticated sender: mullerp) by ms13.u-strasbg.fr (Postfix) with ESMTPSA id 4D79E1FD84; Tue, 6 Aug 2013 17:45:38 +0200 (CEST) From: "Pierre Muller" To: "'Eli Zaretskii'" , References: <83y58evno4.fsf@gnu.org> In-Reply-To: <83y58evno4.fsf@gnu.org> Subject: RE: How to debug fatal exceptions on Windows? Date: Tue, 06 Aug 2013 15:45:00 -0000 Message-ID: <000001ce92bb$ff059a60$fd10cf20$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-08/txt/msg00011.txt.bz2 Hi Eli, I could be that some "special" exception code is=20 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.=20 And the code is then caught by the gnu_exception_handler. =20=20 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 =3D 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=A0: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la p= art > de Eli Zaretskii > Envoy=E9=A0: mardi 6 ao=FBt 2013 17:34 > =C0=A0: gdb@sourceware.org > Objet=A0: How to debug fatal exceptions on Windows? >=20 > I need the help of the wizards here, thanks in advance. >=20 > 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: >=20 > #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=3D11, backtrace_limit=3D= 40) at > emacs.c:344 > #3 0x011472bb in handle_fatal_signal (sig=3D11) at sysdep.c:1638 > #4 0x01147296 in deliver_thread_signal (sig=3D11, handler=3D0x11472a2 > ) at sysdep.c:1614 > #5 0x011472ef in deliver_fatal_thread_signal (sig=3D11) at sysdep.c:16= 50 > #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 ?? () >=20 > gnu_exception_handler is the handler installed by startup. >=20 > 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. >=20 > 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. >=20 > TIA