emacs-devel
[Top][All Lists]
Advanced

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

The emacs_backtrace "feature"


From: Stephen J. Turnbull
Subject: The emacs_backtrace "feature"
Date: Sat, 22 Sep 2012 01:49:50 +0900

Eli Zaretskii writes:

 >    If you didn't make a point of setting up [for a crash], you'll
 >    lose precious information.
[...]
 > Why not use the good old core dump files?  They have all the
 > information that is needed for debugging the crash,

Assuming that they exist.  Sadly, on modern GNU systems (as
distributed by the major distros) they usually don't ... unless the
user makes a point of setting up for a crash.  As you say, people
usually don't.

 > But here we do that voluntarily and by default.  Why?

Because modern GNU systems (as distributed by the major distros)
usually *do* come with installable "debug" packages that contain the
symbol table that gets stripped out by default.  I agree, trying to
find the Corresponding Source for "find_file_internal + 0xDEAD" is
pretty darn annoying, but I've debugged a lot of issues with just the
most recently called function name.

What bugs me a lot more is inability to get at variable values,
especially actual parameters.  But thanks to the wonders of modern
GCC, the value of whatever you're interested in is <variable optimized
out>, so you also get that feature for free with <drum roll>modern GNU
systems as distributed by the major distros.  (I hear that really
recent GDB does a much better job of disentangling most optimizations,
but guess what isn't installed on <drum roll>....)

 > Otherwise, I guess we will find soon enough whether this is a great
 > feature or not.

I agree that core dumps are better (but habitually running under gdb
is even better yet :-).  But it's nice to get at least some
information out of random users who for some strange reason don't
expect Emacs to crash. :-)




reply via email to

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