bug#12908: 24.3.50; file `emacs_backtrace.txt'?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> 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.