Re: C backtraces for Emacs

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]

On 8/22/2012 9:01 AM, Eli Zaretskii wrote:
>> Date: Wed, 22 Aug 2012 02:24:31 -0700
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Cc: Juanma Barranquero <lekktu@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>> 	emacs-devel@gnu.org
>>
>> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]