From: "Paweł Sikora" <pawel.sikora@agmk.net>
To: gdb@sourceware.org, Eli Zaretskii <eliz@gnu.org>
Subject: Re: How to debug fatal exceptions on Windows?
Date: Tue, 06 Aug 2013 18:50:00 -0000 [thread overview]
Message-ID: <2613537.P6K19m4un9@localhost> (raw)
In-Reply-To: <83y58evno4.fsf@gnu.org>
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?
next prev parent reply other threads:[~2013-08-06 18:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-06 15:34 Eli Zaretskii
2013-08-06 15:45 ` Pierre Muller
2013-08-06 18:50 ` Paweł Sikora [this message]
2013-08-06 19:25 ` Eli Zaretskii
[not found] ` <"000001ce92bb$ff059a60$fd10cf20$@muller"@ics-cnrs.unistra.fr>
2013-08-06 16:07 ` Eli Zaretskii
2013-08-09 13:58 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2613537.P6K19m4un9@localhost \
--to=pawel.sikora@agmk.net \
--cc=eliz@gnu.org \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox