From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: The emacs_backtrace "feature" Date: Fri, 21 Sep 2012 12:37:30 -0700 Message-ID: <505CC1FA.4070300@cs.ucla.edu> References: <83lig3yaci.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1348256258 19525 80.91.229.3 (21 Sep 2012 19:37:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Sep 2012 19:37:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 21 21:37:42 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TF92k-0000mV-3H for ged-emacs-devel@m.gmane.org; Fri, 21 Sep 2012 21:37:42 +0200 Original-Received: from localhost ([::1]:39269 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TF92f-0006Ni-Kw for ged-emacs-devel@m.gmane.org; Fri, 21 Sep 2012 15:37:37 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TF92d-0006Nd-2V for emacs-devel@gnu.org; Fri, 21 Sep 2012 15:37:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TF92b-0000Z3-VR for emacs-devel@gnu.org; Fri, 21 Sep 2012 15:37:35 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:48996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TF92Z-0000Xy-VN; Fri, 21 Sep 2012 15:37:32 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 014B439E8013; Fri, 21 Sep 2012 12:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWQgRamTzg+W; Fri, 21 Sep 2012 12:37:30 -0700 (PDT) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 3E7DB39E800D; Fri, 21 Sep 2012 12:37:30 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 In-Reply-To: <83lig3yaci.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153444 Archived-At: 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