[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C backtraces for Emacs

From: Daniel Colascione
Subject: Re: C backtraces for Emacs
Date: Wed, 22 Aug 2012 17:40:08 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

On 8/22/2012 9:01 AM, Eli Zaretskii wrote:
>> Date: Wed, 22 Aug 2012 02:24:31 -0700
>> From: Paul Eggert <address@hidden>
>> Cc: Juanma Barranquero <address@hidden>, Eli Zaretskii <address@hidden>,
>>      address@hidden
>> I'll hold off installing this to give Eli and Juanma a heads-up, as it
>> creates a new substitute header <execinfo.h> on non-GNUish systems,
>> and the Windows build will need to do something similar.  If I understand
>> things correctly Windows already does backtraces in a different way, so
>> its execinfo.h can just be a copy of execinfo.in.h.
> I'm not sure what you mean.  An assertion violation on Windows calls a
> function that displays an abort dialogue, giving the user a chance to
> attach a debugger.  If the user does attach a debugger, she can then
> display a backtrace from the debugger.  There's no other facility to
> display a backtrace on Windows that I'm aware of.

You can use the StackWalk64 function from dbghelp.dll.

"The StackWalk64 function provides a portable method for obtaining a stack
trace. Using the StackWalk64 function is recommended over writing your own
function because of all the complexities associated with stack walking on
platforms. In addition, there are compiler options that cause the stack to
appear differently, depending on how the module is compiled. By using this
function, your application has a portable stack trace that continues to work as
the compiler and operating system change."

Despite its name, StackWalk64 works on 32-bit platforms too. Windows actually
has very good support for this kind of thing.

By the way: when we assert, we should kill Emacs using RaiseFailFastException.
This function produces a nice WER (Windows Error Reporting) dialog and bypasses
a lot of layers of exception handling machinery that would ordinarily run in
userspace --- that is, with RaiseFailFastException, fewer things can go wrong.
abort() under Windows actually tried to run global destructors, send messages to
loaded DLLs about pending process termination, and a bunch of other things. RFFE
is much more reliable. On systems without RFFE, plain old RaiseException is fine
too, and RaiseException is present on all supported Windows versions.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]