From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8535 invoked by alias); 6 Aug 2013 18:50:15 -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 8509 invoked by uid 89); 6 Aug 2013 18:50:14 -0000 X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=BAYES_50,KHOP_THREADED,RDNS_NONE,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mail.agmk.net) (91.192.224.71) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 06 Aug 2013 18:50:12 +0000 Received: from localhost.localnet (unknown [78.131.183.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pluto@agmk.net) by mail.agmk.net (Postfix) with ESMTPSA id 53127E25146; Tue, 6 Aug 2013 20:49:35 +0200 (CEST) From: =?utf-8?B?UGF3ZcWC?= Sikora To: gdb@sourceware.org, Eli Zaretskii Subject: Re: How to debug fatal exceptions on Windows? Date: Tue, 06 Aug 2013 18:50:00 -0000 Message-ID: <2613537.P6K19m4un9@localhost> User-Agent: KMail/4.10.4 (Linux/3.9.11-1; KDE/4.10.5; x86_64; ; ) In-Reply-To: <83y58evno4.fsf@gnu.org> References: <83y58evno4.fsf@gnu.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-SW-Source: 2013-08/txt/msg00013.txt.bz2 On Tuesday 06 of August 2013 18:34:03 Eli Zaretskii wrote: > 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/SYS= TEM32/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? from the winapi level you can use AddVectoredExceptionHandler (winapi) to i= nstall 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=C5=82. --=20 A: Because it breaks the logical sequence of discussion Q: Why is top posting bad?