From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Fri, 16 Nov 2012 21:39:01 +0200 Message-ID: <837gpl49t6.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <838va14blm.fsf@gnu.org> <5F469B1E1F824FA8B16159BB2E0DE869@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1353094882 24009 80.91.229.3 (16 Nov 2012 19:41:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Nov 2012 19:41:22 +0000 (UTC) Cc: 12908@debbugs.gnu.org, 12908-done@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 16 20:41:32 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1TZRn9-0002Nb-UW for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Nov 2012 20:41:32 +0100 Original-Received: from localhost ([::1]:39873 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZRmz-0003yy-SR for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Nov 2012 14:41:21 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZRmv-0003xu-Rq for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 14:41:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZRms-0006jg-Pn for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 14:41:17 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZRms-0006ja-MC for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 14:41:14 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TZRne-0001xJ-FJ for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 14:42:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Nov 2012 19:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12908 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12908-submit@debbugs.gnu.org id=B12908.13530948657448 (code B ref 12908); Fri, 16 Nov 2012 19:42:02 +0000 Original-Received: (at 12908) by debbugs.gnu.org; 16 Nov 2012 19:41:05 +0000 Original-Received: from localhost ([127.0.0.1]:49103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRmi-0001w1-Ef for submit@debbugs.gnu.org; Fri, 16 Nov 2012 14:41:05 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:38267) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRme-0001vU-Bv; Fri, 16 Nov 2012 14:41:01 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDL00E00I6D7C00@a-mtaout22.012.net.il>; Fri, 16 Nov 2012 21:39:32 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDL00D22ILV6ZL0@a-mtaout22.012.net.il>; Fri, 16 Nov 2012 21:39:32 +0200 (IST) In-reply-to: <5F469B1E1F824FA8B16159BB2E0DE869@us.oracle.com> X-012-Sender: halo1@inter.net.il X-Spam-Score: 1.5 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-Spam-Score: 1.5 (+) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:67024 Archived-At: > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org>, <12908-done@debbugs.gnu.org> > Date: Fri, 16 Nov 2012 11:22:51 -0800 > > > It's written in the current directory of the Emacs process, and only > > if you click NO on the abort dialog. > > I don't understand. If you click NO then you are saying that you do NOT want to > participate in debugging the crash. No, you say that you don't want to attach a debugger. > Why would Emacs insist in that case in writing a backtrace file for > debugging to your hard drive? Don't ask me, I just implemented on Windows what Emacs does on GNU and Unix platforms. When this was suggested, I posted a message describing the disadvantages of this method, see http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00501.html But the feature was implemented nonetheless. So now it's part Emacs, on Unix and Windows alike. > That does not seem very friendly (or useful) on the part of Emacs. There are gobs of programs writing to your disk right now, without asking for your permission. What's so unfriendly in Emacs doing the same? > > It contains the call-stack backtrace, which could be used to find the > > sequence of function calls that led to the crash. Similar to what GDB > > produces when you type "bt". > > So it could be used for debugging. But it is written only if a user says that > s?he does NOT want to debug the crash. Yes. We, the Emacs maintainers, expect you to submit that file for us to debug the problem. > > Users should include it with their bug reports. > > Does my having included it in this bug report help in some way? > I'm guessing no, but would love to be shown wrong. Your guess is wrong, that file includes enough information to understand where the crash happened, and in some cases also why. > > If you have the addr2line.exe program on your disk, you can > > produce a more readable backtrace from these numbers, see > > the Emacs user manual for details. > > And if you do not have addr2line? Then I do. > Is the backtrace really useful for anyone in that case? Did the > backtrace I included here help at all? Yes. Anyone with addr2line.exe can run it and recover the source file names and line numbers where the crash happened. > > > and control whether and where it is written > > > > You can't. It's always written in the current directory of the Emacs > > process, which is normally a single directory determined by what your > > desktop shortcut says. > > Why not let users decide where the file is written, and record that directory > (of the process) as part of the file content (or record it elsewhere)? Because (a) that's how Emacs works on other platforms, and (b) consulting Lisp when Emacs caught a fatal error is dangerous (could produce another fatal error). > Sounds like shades of Unix .core files. It is, indeed. > At least there are ways for users to turn off writing such coredumps > (and even ways to turn that off selectively, for given directories). Which is bad for maintainers, because users then flood them with worthless bug reports that cannot be acted upon. > You've closed the bug, considering, I imagine, that it is only a doc bug and > that you have now documented it, so end of story. End of _this_ story, yes. > I don't see it that way. Emacs is now writing something to arbitrary user > directories. That is something new and not necessarily always welcome. Please > consider working on this aspect some more. Thx. Then please submit another bug report, which is not Windows specific and not about the documentation of this file. If the general Emacs behavior changes, so will its behavior on Windows.