From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Fri, 16 Nov 2012 12:56:55 -0800 Message-ID: <263AC1B3AE7347CEAA88A5723B1C7A7F@us.oracle.com> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <838va14blm.fsf@gnu.org> <5F469B1E1F824FA8B16159BB2E0DE869@us.oracle.com> <837gpl49t6.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1353099445 30638 80.91.229.3 (16 Nov 2012 20:57:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Nov 2012 20:57:25 +0000 (UTC) Cc: 12908@debbugs.gnu.org, 12908-done@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 16 21:57:33 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 1TZSyi-00031j-GT for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Nov 2012 21:57:32 +0100 Original-Received: from localhost ([::1]:55352 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZSyY-0004jf-Eu for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Nov 2012 15:57:22 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZSyT-0004jL-Dh for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 15:57:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZSyQ-0007Yq-BC for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 15:57:17 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZSyQ-0007Yl-7z for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 15:57:14 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TZSzC-0004ZQ-4h for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 15:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Nov 2012 20:58: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.135309947517555 (code B ref 12908); Fri, 16 Nov 2012 20:58:02 +0000 Original-Received: (at 12908) by debbugs.gnu.org; 16 Nov 2012 20:57:55 +0000 Original-Received: from localhost ([127.0.0.1]:49302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZSz4-0004Z2-4n for submit@debbugs.gnu.org; Fri, 16 Nov 2012 15:57:54 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:40203) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZSz1-0004Ym-4T; Fri, 16 Nov 2012 15:57:52 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAGKv0JN006596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Nov 2012 20:57:01 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAGKv0KE010858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2012 20:57:00 GMT Original-Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAGKuxVc019657; Fri, 16 Nov 2012 14:56:59 -0600 Original-Received: from dradamslap1 (/10.159.229.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Nov 2012 12:56:59 -0800 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <837gpl49t6.fsf@gnu.org> Thread-Index: Ac3EMjKasJxrsCMaRPKqjI8PgAupagABp/Ag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-Spam-Score: 0.7 (/) 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:67027 Archived-At: > > 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. Thanks for the background. > > 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? I don't have gobs of programs writing to arbitrary directories, especially directories with user files. AFAIK, I have NO programs doing that. If whether such writing is done cannot be controlled by a user (not good, IMHO), then Emacs should at least write the information to a "hidden", more or less "internal" directory, such as .emacs.d. Putting this stuff willy nilly in user directories is a bad idea, IMO. Not at all user-friendly. (And that's regardless of whether Emacs feels free to do this on some other platforms. Emacs being rude elsewhere is not a good excuse for it to be rude on Windows too.) > 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. That's good news. Let's hope it helps fix some of the crashing problems. > > 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. Very good. > > 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). a1. It is Emacs maintainers who decide how Emacs should work - on any platform. a2. "That's how Emacs works" is false: It is not true in any Emacs release. It is true only in code under development that is being _proposed_ for release. Hardly a "that's just how it is" precedent. b. Why would Lisp need to be consulted? But if there is no better alternative, a user's choice could be recorded in a file that is read before writing emacs_backtrace.txt. Of course, you will perhaps say the same thing wrt opening a file... I realize that might be problematic. (But at least it is not rude.) > > 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. Well, one of the main reasons people prevent coredumps in Unix is that they are costly in time & space. That of course does not apply here. I don't see a crying need to prevent writing these backtrace files. I do see a need (a courtesy to users) for letting users decide where to put them. Or barring that possibility, at least a need to confine them to someplace under .emacs.d. > 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. Done (#12911). But it is you, not I, who chooses to characterizes this bug as being about only doc and only MS Windows. Please reread the subject line.