Re: The emacs_backtrace "feature"

[Paul Eggert <eggert@cs.ucla.edu>]

I agree with a lot of points that Eli raised: backtraces can be a
pain.  Still, in my experience these backtraces, limited as they
are, are typically an improvement over not having backtraces.

Going through some of Eli's comments:

>  . Many real-life backtraces are long and quickly scroll off the
>    screen.

That's less of a problem these days.  On GNU and POSIXish
platforms most people run Emacs in an environment where backtraces
are sent to a file, or to a window or a console that has history
that is typically long enough.  It's not perfect, but it's
typically better than not having a backtrace.

>  . Many calls to emacs_backtrace in the current sources limit the
>    number of backtrace frames to 10, but that is an arbitrary
>    limitation which will be too small in most, if not all, situations.

We can change that number if needed.  10 was enough for my use
cases.  Of course no number will be ideal in all cases.  Still, 10
is almost invariably better than 0.

>  . The backtrace is written to the standard error file handle.  Is
>    that handle always guaranteed to be available

No.  But typically it is, and overall we're better off.

>  . using the limited information it provides can be quite
>    difficult, especially if the crash happened in a binary
>    compiled by a different compiler version than yours

I'd say it's more than just "difficult".  It's typically impossible.
A backtrace makes sense only if you have access to the environment
that generated the crash, or a pretty-close clone of that
environment.  In this respect it's no better than a core dump.

Core dumps are better than backtraces if they're available, but
modern GNUish distributions often disable them, alas, and they're
a pain to send via email, and it's nice to have a bit more info
than 'Fatal error 27' when Emacs crashes.

The main point of these backtraces is to help diagnose Emacs
problems after a crash in which a core dump is not available and
where the bug cannot easily be reproduced.  This situation is
becoming increasinly common, and for this situation a backtrace,
even with its limitations, is invaluable.  Anyone with access to
the system where the crash occurred can use GDB or addr2line to
get the source line numbers etc. for the crash.  This is info
that's available in no other way.

Come to think of it, the addr2line stuff should be documented.  I
gave it a shot and installed the following as trunk bzr 110125.

* trouble.texi (Crashing): Document addr2line.
=== modified file 'doc/emacs/trouble.texi'
--- doc/emacs/trouble.texi	2012-09-04 18:29:04 +0000
+++ doc/emacs/trouble.texi	2012-09-21 19:27:37 +0000
@@ -308,13 +308,26 @@

 @noindent
 The number @samp{11} is the system signal number that corresponds to
-the problem, a segmentation fault here.  The hexadecimal program
-addresses can be useful in debugging sessions.  For example, the GDB
-command @samp{list *0x509af6} prints the source-code lines
-corresponding to the @samp{emacs[0x509af6]} entry in the backtrace.
-
-The three dots at the end indicate that Emacs suppressed further
-backtrace entries, in the interest of brevity.
+the problem, a segmentation fault here.  The three dots at the end
+indicate that Emacs suppressed further backtrace entries, in the
+interest of brevity.
+
+The hexadecimal program addresses can be useful in debugging sessions.
+For example, the GDB command @samp{list *0x509af6} prints the
+source-code lines corresponding to the @samp{emacs[0x509af6]} entry in
+the backtrace.  Or, if your system has @command{addr2line}, the
+following shell command outputs a backtrace with source-code line
+numbers:
+
+@example
+sed -n 's/.*\[\(.*\)]$/\1/p' @var{backtrace} |
+  addr2line -Cfip -e @var{bindir}/emacs
+@end example
+
+@noindent
+Here, @var{backtrace} is the name of a text file containing a copy of
+the backtrace, and @var{bindir} is the name of the directory that
+contains the Emacs executable.

 @node After a Crash
 @subsection Recovery After a Crash