GNU bug report logs - #12908
24.3.50; file `emacs_backtrace.txt'?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12908 in the body.
You can then email your comments to 12908 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50; file `emacs_backtrace.txt'?
Date: Fri, 16 Nov 2012 10:30:34 -0800

Still getting many crashes (every session), but now I notice that Emacs
is creating a file `emacs_backtrace.txt' in the current directory (or
perhaps it is in the dir in which Emacs was started?).
 
I looked in the Emacs manual, the Elisp manual, and NEWS for some
information about this file, but found nothing (so there is a doc bug,
at least).
 
What is the file for, how are users to use it and control whether and
where it is written, etc.?
 
Here is the content of one such file, in case it helps in some way
(which I doubt):
 

Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x012072B8
0x012080B9
0x0103B54F
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x01063E40
0x010030FF
0x01001411
0x01021A07
0x01208B6F
0x01206FA0
0x01203D74
0x0103B556
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01144D4F
0x01144D2A
0x01144D83
0x010011E6
0x7C8438F6
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01144D4F
0x01144D2A
0x01144D83
0x010011E6
0x7C8438F6
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x01063E40
0x010030FF
0x01001411
0x01021A07
0x01271987
0x012753CF
0x01201334
0x01202410
0x0121160D
0x01208C14
0x01010FC6
0x01208BA1
0x01206FA0
0x01203D74
0x0103B556
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x010EFEEA
0x010F6A68
0x010F5208
0x010F48F4
0x010F4616
0x0120710E
0x01203D74
0x0103B556
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01144D4F
0x01144D2A
0x01144D83
0x010011E6
0x7C8438F6
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x012D32D3
0x01014F64
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E6C1C
0x01014FD5
0x01014733
0x01052C55
0x010390C7
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-11-05 on MS-W7-DANI
Bzr revision: 110809 lekktu <at> gmail.com-20121105172930-a5gn0bwi4lndchhw
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src
 -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5
 -I../../libs/giflib-4.1.4-1-lib/include
 -I../../libs/jpeg-6b-4-lib/include
 -I../../libs/tiff-3.8.2-1-lib/include
 -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2
 -I../../libs/gnutls-3.0.9-w32-bin/include
 -I../../libs/libiconv-1.9.2-1-lib/include'
 

Message #8 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Fri, 16 Nov 2012 19:40:46 +0100

On Fri, Nov 16, 2012 at 7:30 PM, Drew Adams <drew.adams <at> oracle.com> wrote:

> I looked in the Emacs manual, the Elisp manual, and NEWS for some
> information about this file, but found nothing (so there is a doc bug,
> at least).

Yes.

> What is the file for, how are users to use it and control whether and
> where it is written, etc.?

2012-11-02  Eli Zaretskii  <eliz <at> gnu.org>

        Implement backtrace output for fatal errors on MS-Windows.
        * w32fns.c (CaptureStackBackTrace_proc): New typedef.
        (BACKTRACE_LIMIT_MAX): New macro.
        (w32_backtrace): New function.
        (emacs_abort): Use w32_backtrace when the user chooses not to
        attach a debugger.  Update the text of the abort dialog.

Currently you cannot control where it is written.

As for how to use it, if you have MinGW installed you can use addr2line:

addr2line -e /path/to/emacs.exe < emacs_backtrace.txt

    Juanma

Message #13 received at 12908-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 12908-done <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Fri, 16 Nov 2012 21:00:21 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Fri, 16 Nov 2012 10:30:34 -0800
> 
> Still getting many crashes (every session), but now I notice that Emacs
> is creating a file `emacs_backtrace.txt' in the current directory (or
> perhaps it is in the dir in which Emacs was started?).

It's written in the current directory of the Emacs process, and only
if you click NO on the abort dialog.

> I looked in the Emacs manual, the Elisp manual, and NEWS for some
> information about this file, but found nothing (so there is a doc bug,
> at least).

Right, now fixed (revision 110913 on the trunk).

> What is the file for

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".

> how are users to use it

Users should include it with their bug reports.  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 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.

Message #16 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juanma Barranquero'" <lekktu <at> gmail.com>
Cc: 12908 <at> debbugs.gnu.org
Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Fri, 16 Nov 2012 11:08:16 -0800

> > What is the file for, how are users to use it and control 
> > whether and where it is written, etc.?
> 
>         Implement backtrace output for fatal errors on MS-Windows.
>         * w32fns.c (CaptureStackBackTrace_proc): New typedef.
>         (BACKTRACE_LIMIT_MAX): New macro.
>         (w32_backtrace): New function.
>         (emacs_abort): Use w32_backtrace when the user chooses not to
>         attach a debugger.  Update the text of the abort dialog.
> 
> Currently you cannot control where it is written.

Thanks for the info.

Can you at least control _whether_ it is written?

> As for how to use it, if you have MinGW installed you can use 
> addr2line: addr2line -e /path/to/emacs.exe < emacs_backtrace.txt

(Which does what?)

If you do *not* have MinGW installed then is it the case that you can do nothing
with the file?  If so then, in that case at least, users should have an easy way
to turn off writing the file (which no one can use).

Is there some way (e.g. an env var to check?) that Emacs can itself know whether
MinGW is installed, so that at least in the case where it is not it can inhibit
writing the file (by default - obviously to be overridable by users)?

The file is not big (at least it wasn't in the case I had), so I don't mind
Emacs writing it, even though I cannot use it.  But I think users should be able
to control whether and where it gets written.

And I'm thinking that the default location should perhaps be somewhere under
.emacs.d, perhaps with the dir that is currently used as the default recorded
somehow.

Message #19 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 12908 <at> debbugs.gnu.org, 12908-done <at> debbugs.gnu.org
Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
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.  Why would Emacs insist in that case in
writing a backtrace file for debugging to your hard drive?

That does not seem very friendly (or useful) on the part of Emacs.

> > I looked in the Emacs manual, the Elisp manual, and NEWS for some
> > information about this file, but found nothing (so there is 
> > a doc bug, at least).
> 
> Right, now fixed (revision 110913 on the trunk).
> 
> > What is the file for
> 
> 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.

I understand that such a NO means, in particular, that s?he does not want to use
gdb, but it can also mean that s?he does not want to bother with any debugging
etc.  Why assume that s?he wants a backtrace file written?

> > how are users to use it
> 
> 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.

> 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?  Is the backtrace really useful for anyone in
that case?  Did the backtrace I included here help at all?
(Not rhetorical questions.)

> > 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)?

Sounds like shades of Unix .core files.  At least there are ways for users to
turn off writing such coredumps (and even ways to turn that off selectively, for
given directories).

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.

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.

Message #25 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 12908 <at> debbugs.gnu.org, 12908-done <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Fri, 16 Nov 2012 21:39:01 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <12908 <at> debbugs.gnu.org>, <12908-done <at> 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.

Message #31 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: lekktu <at> gmail.com, 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Fri, 16 Nov 2012 21:42:06 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Fri, 16 Nov 2012 11:08:16 -0800
> Cc: 12908 <at> debbugs.gnu.org
> 
> Can you at least control _whether_ it is written?

No.  But you can set up a scheduled task to delete it every day, if
you wish.  You can even do this in Emacs, using the midnight.el
package.

> And I'm thinking that the default location should perhaps be somewhere under
> .emacs.d, perhaps with the dir that is currently used as the default recorded
> somehow.

This is dangerous, because accessing the home directory may involve
Lisp evaluation, e.g. if that directory is remote.  This facility must
be as simple and close to the bare metal as possible, or else it will
be more trouble than help.

Message #34 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 12908 <at> debbugs.gnu.org, 12908-done <at> debbugs.gnu.org
Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Fri, 16 Nov 2012 12:56:55 -0800

> > 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.

Message #40 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 12908 <at> debbugs.gnu.org
Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Fri, 16 Nov 2012 13:02:27 -0800

> > And I'm thinking that the default location should perhaps 
> > be somewhere under .emacs.d, perhaps with the dir that is
> > currently used as the default recorded somehow.
> 
> This is dangerous, because accessing the home directory may involve
> Lisp evaluation, e.g. if that directory is remote.  This facility must
> be as simple and close to the bare metal as possible, or else it will
> be more trouble than help.

Then put it under the Emacs installation directory.

The point is to get it away from user files.  Please use your imagination.  If
there are good reasons why you cannot easily put it here or there, then try
somewhere else - but aim for somewhere that does not interfere with user data.

A users looking in her folder of recipes should not find an Emacs debugging
file.  That should be a no-brainer, at least in terms of goal.

Message #43 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 12908 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Fri, 16 Nov 2012 16:49:22 -0500

>> And I'm thinking that the default location should perhaps be
>> somewhere under .emacs.d, perhaps with the dir that is currently used
>> as the default recorded somehow.
> This is dangerous, because accessing the home directory may involve
> Lisp evaluation, e.g. if that directory is remote.

If the ~/.emacs.d is under some file-handler like Tramp, then we're out
of luck, but I wouldn't worry about it.  Just pass the file names to the
OS's functions and if it can't handle them, then you'll get a write
error and that's that (we have to handle that case anyway).


        Stefan

Message #46 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 09:21:42 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <12908 <at> debbugs.gnu.org>, <12908-done <at> debbugs.gnu.org>
> Date: Fri, 16 Nov 2012 12:56:55 -0800
> 
> > > 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.

Yes, you do.  You just don't know that.  If you are really interested,
you could try walking the process tree with Process Explorer and
looking at the files they have open and amount of I/O on those files.

> > 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.

The details of the same feature on Unix were already in NEWS and in
the manual, and emacs_backtrace.txt is a Windows-only file name (it
has different names on Unix, as documented in the manual).  So I don't
see how your original report could have been interpreted in any other
way than I did.

Message #49 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: lekktu <at> gmail.com, 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 09:23:12 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <lekktu <at> gmail.com>, <12908 <at> debbugs.gnu.org>
> Date: Fri, 16 Nov 2012 13:02:27 -0800
> 
> > > And I'm thinking that the default location should perhaps 
> > > be somewhere under .emacs.d, perhaps with the dir that is
> > > currently used as the default recorded somehow.
> > 
> > This is dangerous, because accessing the home directory may involve
> > Lisp evaluation, e.g. if that directory is remote.  This facility must
> > be as simple and close to the bare metal as possible, or else it will
> > be more trouble than help.
> 
> Then put it under the Emacs installation directory.
> 
> The point is to get it away from user files.

Again, I just mimicked the behavior on Unix, as best as possible.
Please read the manual to learn where this information is put on Unix.

Message #52 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: lekktu <at> gmail.com, 12908 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 09:27:43 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Drew Adams <drew.adams <at> oracle.com>,  lekktu <at> gmail.com,  12908 <at> debbugs.gnu.org
> Date: Fri, 16 Nov 2012 16:49:22 -0500
> 
> >> And I'm thinking that the default location should perhaps be
> >> somewhere under .emacs.d, perhaps with the dir that is currently used
> >> as the default recorded somehow.
> > This is dangerous, because accessing the home directory may involve
> > Lisp evaluation, e.g. if that directory is remote.
> 
> If the ~/.emacs.d is under some file-handler like Tramp, then we're out
> of luck, but I wouldn't worry about it.  Just pass the file names to the
> OS's functions and if it can't handle them, then you'll get a write
> error and that's that (we have to handle that case anyway).

Fine with me.  I will change the Windows code when the Unix code is
changed along these lines.

Message #55 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 12908 <at> debbugs.gnu.org
Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 08:36:52 -0800

> > Then put it under the Emacs installation directory.
> > The point is to get it away from user files.
> 
> Again, I just mimicked the behavior on Unix, as best as possible.
> Please read the manual to learn where this information is put on Unix.

No one is blaming you, and certainly not for making things consistent with what
is done on Unix.  You have pointed out that the bug (annoyance) exists on Unix
also.  Fine.  So let's correct it everywhere.

Message #58 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 12908 <at> debbugs.gnu.org
Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 08:36:52 -0800

> > > > 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.
> 
> Yes, you do.  You just don't know that.  If you are really interested,
> you could try walking the process tree with Process Explorer and
> looking at the files they have open and amount of I/O on those files.

Let me put it this way, since I haven't been able to make it clear enough so
far: I do not _se+_ files created in my user folders.  If there are such files
created, whether temporarily or permanently, I am unaware of it.  Not so with
emacs_backtrace.txt files.

That is the point: the behavior that users witness - the user experience.  I
will not argue with you that there no such files are ever created by other
programs.  I will say that I don't see any such.

Nothing about what other programs are doing is annoying in this respect.  If you
want to make Emacs not be annoying in the same way, please do.

It is the user-level annoyance that this bug report is about.  Users do not know
or care about the implementation level at which you are examining the issue.

Your answers do not address the issue, which is user annoyance at the _obvious_
creation of uninvited files in their folders.  You may prove that I
misunderstand this or that about what other programs do under the covers, but
you are missing the point: what users see (and will be annoyed by).

> > > 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.
> 
> The details of the same feature on Unix were already in NEWS and in
> the manual, and emacs_backtrace.txt is a Windows-only file name (it
> has different names on Unix, as documented in the manual).  So I don't
> see how your original report could have been interpreted in any other
> way than I did.

Even when the OP informs you that your interpretation is wrong (too limited)?
Anyway, there is now another bug for the annoyance, and thank you for
documenting the annoyance.  I have no problem with splitting the bug report that
way.

Message #61 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 12908 <at> debbugs.gnu.org
Subject: Re: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 10:45:00 -0800

There seems to be some misunderstanding here.  The Unix code does
not write into $HOME/backtrace.txt, or into $HOME, or into anywhere
like that.  It writes to stderr.  The programs that invoke Emacs
(normally window managers) arrange for the standard error stream
to be sent to a suitable place.

The Microsoft Windows code does something different: it writes the
backtrace both to stderr and to a file emacs_backtrace.txt.

If the goal is to mimic the Unix behavior as closely as possible, then
the fix should be simple: output the backtrace just to stderr, as
the Unix code does.  Perhaps there are reasons not to do that
on Microsoft Windows, but as these reasons are specific to that
platform it would seem that any fix would be platform-specific
as well.

Message #64 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 21:09:27 +0200

> Date: Sat, 17 Nov 2012 10:45:00 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> There seems to be some misunderstanding here.  The Unix code does
> not write into $HOME/backtrace.txt, or into $HOME, or into anywhere
> like that.  It writes to stderr.  The programs that invoke Emacs
> (normally window managers) arrange for the standard error stream
> to be sent to a suitable place.

That suitable place is in a subdirectory of the user's home directory,
at least on the most popular systems, according to the Emacs manual.

> The Microsoft Windows code does something different: it writes the
> backtrace both to stderr and to a file emacs_backtrace.txt.

Yes.

> If the goal is to mimic the Unix behavior as closely as possible, then
> the fix should be simple: output the backtrace just to stderr, as
> the Unix code does.

This will not work: unlike Unix, a GUI program invoked on Windows
from a desktop icon normally has its standard error stream closed.  So
writing there will end up nowhere.  That is why my implementation
writes both to stderr and to the file; in the worst (or best?) case,
you have two copies of the information, but you always have at least
one.

> Perhaps there are reasons not to do that on Microsoft Windows, but
> as these reasons are specific to that platform it would seem that
> any fix would be platform-specific as well.

I don't see it that way.  If what the Unix code writes to stderr ends
up in some random location under the user's home directory, or even in
a place whose whereabouts no one knows, then I see no reason not to
write it on Windows in the current directory of the Emacs process.
(Note that unlike on Unix, Emacs on Windows doesn't change its current
directory from where it was started, so the backtrace will normally
end up in the same directory for all invocations of Emacs on that
machine by that user.)

If we want the information in .emacs.d, we need to actively write it
there on Unix.

Message #67 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 11:29:47 -0800

On 11/17/2012 11:09 AM, Eli Zaretskii wrote:

> That suitable place is in a subdirectory of the user's home directory,
> at least on the most popular systems, according to the Emacs manual.

Sure, but it's under the user's control, and it's easy to
change the default.  I'm not a typical user, but I'd guess
that about half the time I put stderr some place other
than the default, because I start up Emacs from a terminal
session or suchlike.  And when Emacs is being debugged, stderr
is almost never put into a home-directory file.

> unlike Unix, a GUI program invoked on Windows
> from a desktop icon normally has its standard error stream closed.

This is a problem not just for backtraces, but for everything that
Emacs sends to stderr.  Perhaps it would be better for Emacs, on
Microsoft Windows, to redirect stderr to a file, so that the information
does not get lost.  That file would serve the function that
emacs_backtrace.txt serves now, but it would also capture all the
other stuff that goes to stderr and currently gets lost.

Even if we continue to restrict the contents of the file to
backtraces, the name of this file is something that is specific
to the Microsoft Windows version of Emacs, so the GNU and Unix versions
don't have to worry about the file's name.

> (Note that unlike on Unix, Emacs on Windows doesn't change its current
> directory from where it was started

No, Emacs is the same on both platforms.  The main Emacs process doesn't
invoke chdir on GNU or Unix either, unless you use the --chdir option.

Message #70 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 21:42:31 +0200

> Date: Sat, 17 Nov 2012 11:29:47 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 12908 <at> debbugs.gnu.org
> 
> On 11/17/2012 11:09 AM, Eli Zaretskii wrote:
> 
> > That suitable place is in a subdirectory of the user's home directory,
> > at least on the most popular systems, according to the Emacs manual.
> 
> Sure, but it's under the user's control, and it's easy to
> change the default.

Unless we are going to ask each Emacs user to change the default so
that the file ends up in .emacs.d, we still have a discrepancy vs what
Stefan asked to do.

> > unlike Unix, a GUI program invoked on Windows
> > from a desktop icon normally has its standard error stream closed.
> 
> This is a problem not just for backtraces, but for everything that
> Emacs sends to stderr.

Which is nothing on Windows, except in debug builds with non-default
options turned on, which are used only by experts (who know how not to
lose this stuff).

> Perhaps it would be better for Emacs, on Microsoft Windows, to
> redirect stderr to a file, so that the information does not get
> lost.

It's not easy to do that, and it isn't worth the trouble, see above.
But if someone volunteers to do that, my hat's off.  Until then, we
cannot safely use stderr on Windows for information we cannot afford
losing.

Message #73 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 13:25:17 -0800

On 11/17/2012 11:42 AM, Eli Zaretskii wrote:

> Unless we are going to ask each Emacs user to change the default so
> that the file ends up in .emacs.d, we still have a discrepancy vs what
> Stefan asked to do.

I must have missed that request; all I see from him in Bug#12908
is a comment about how to deal with the file names under the
assumption that Emacs itself redirects stderr to a file
whose name Emacs chooses.  That assumption is currently true on
Microsoft Windows for backtraces, but it's not true for GNU and Unix
where we don't have the problem.

>> Perhaps it would be better for Emacs, on Microsoft Windows, to
>> redirect stderr to a file, so that the information does not get
>> lost.
> 
> It's not easy to do that

Can Emacs use freopen?  For example, the
following code would do the job on a POSIX platform:
if stderr is closed, it redirects it to emacs-stderr.txt
in the current directory, if possible.  Would this sort of thing
work on Microsoft platform?

=== modified file 'src/emacs.c'
--- src/emacs.c	2012-11-08 19:12:23 +0000
+++ src/emacs.c	2012-11-17 21:23:46 +0000
@@ -748,6 +748,11 @@ main (int argc, char **argv)
     unexec_init_emacs_zone ();
 #endif
 
+#ifdef DOS_NT
+  if (dup2 (STDERR_FILENO, STDERR_FILENO) < 0)
+    ignore_value (freopen ("emacs-stderr.txt", "a", stderr));
+#endif
+
   atexit (close_output_streams);
 
   sort_args (argc, argv);

Message #76 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>, "'Paul Eggert'" <eggert <at> cs.ucla.edu>
Cc: 12908 <at> debbugs.gnu.org
Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 15:01:40 -0800

(I see that everyone is using the original bug thread, even though I created a
new one at Eli's request, and the original one was supposedly closed (doc
fixed).)

> (Note that unlike on Unix, Emacs on Windows doesn't change its current
> directory from where it was started, so the backtrace will normally
> end up in the same directory for all invocations of Emacs on that
> machine by that user.)
> 
> If we want the information in .emacs.d, we need to actively write it
> there on Unix.

On Windows, I believe that some (many? most?) users start Emacs from a shortcut,
and that some (many? most?) of those start it in a directory that has meaning
for them, e.g., a directory of user files.

(I, for example, start it in a directory of my Emacs Lisp files, and I open it
with Dired there.)

Is the situation similar on Unix?  Do users often start Emacs in a user
directory?

It's one thing to stick the backtrace file in the startup directory if that is
the default Emacs bin directory or some such Emacs-related folder.  It's another
thing to stick the file in a user directory because the user intentionally
starts Emacs there.

That has been my point from the beginning: I don't really care where you stick
it, as long as it is in some Emacs/system internal program folder and not a user
folder.

There is a reason why programs on Windows are often installed (and started) in
an application-specific folder under `Program Files', and not in any old user
folder.

Message #79 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Paul Eggert'" <eggert <at> cs.ucla.edu>, "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 12911 <at> debbugs.gnu.org, 12908 <at> debbugs.gnu.org
Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 15:08:17 -0800

> > Unless we are going to ask each Emacs user to change the default so
> > that the file ends up in .emacs.d, we still have a 
> > discrepancy vs what Stefan asked to do.
> 
> I must have missed that request; all I see from him in Bug#12908
> is a comment about how to deal with the file names

That's because Stefan wrote it in the proper bug thread, and not in this one
(which Eli asked us to abandon (but which he too continues to populate)):

> From: Stefan Monnier Sent: Friday, November 16, 2012 1:20 PM
> To: Drew Adams Cc: 12911 <at> debbugs.gnu.org
> Subject: Re: bug#12911: 24.3.50; let users decide where (& 
> perhaps whether) `emacs_backtrace.txt' files are written
> 
> > If such user control is not possible, then please confine 
> > such files to somewhere under .emacs.d or some other
> > "hidden" directory that is
> 
> Agreed: writing the file into ~/.emacs.d makes a lot more sense.
> 
>         Stefan

Message #82 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 'Eli Zaretskii' <eliz <at> gnu.org>, 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 17:12:01 -0800

On 11/17/2012 03:08 PM, Drew Adams wrote:
>> I must have missed that request; all I see from him in Bug#12908
>> > is a comment about how to deal with the file names
> That's because Stefan wrote it in the proper bug thread, and not in this one

Ah, OK, I'll respond there.

Message #85 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 17:24:04 -0800

On 11/17/2012 03:01 PM, Drew Adams wrote:
> Is the situation similar on Unix?  Do users often start Emacs in a user
> directory?

Yes, that's common.  But it doesn't lead to backtrace
files appearing in user directories, because Emacs does
not create backtrace files on Unix; it merely writes the
backtraces to stderr.

Message #88 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: eggert <at> cs.ucla.edu, 12911 <at> debbugs.gnu.org, 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sun, 18 Nov 2012 05:56:53 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <12908 <at> debbugs.gnu.org>, <12911 <at> debbugs.gnu.org>
> Date: Sat, 17 Nov 2012 15:08:17 -0800
> 
> > > Unless we are going to ask each Emacs user to change the default so
> > > that the file ends up in .emacs.d, we still have a 
> > > discrepancy vs what Stefan asked to do.
> > 
> > I must have missed that request; all I see from him in Bug#12908
> > is a comment about how to deal with the file names
> 
> That's because Stefan wrote it in the proper bug thread, and not in this one
> (which Eli asked us to abandon (but which he too continues to populate)):

I just reply to messages of others.  I cannot afford reading the
headers, nor keeping in mind all the bug numbers.

Message #91 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: eggert <at> cs.ucla.edu, 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sun, 18 Nov 2012 05:58:21 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <12908 <at> debbugs.gnu.org>
> Date: Sat, 17 Nov 2012 15:01:40 -0800
> 
> That has been my point from the beginning: I don't really care where
> you stick it, as long as it is in some Emacs/system internal program
> folder and not a user folder.

On Unix, the data winds up in some directory under user's home
directory.  See the manual.

Message #94 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sun, 18 Nov 2012 06:04:28 +0200

> Date: Sat, 17 Nov 2012 13:25:17 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 12908 <at> debbugs.gnu.org
> 
> >> Perhaps it would be better for Emacs, on Microsoft Windows, to
> >> redirect stderr to a file, so that the information does not get
> >> lost.
> > 
> > It's not easy to do that
> 
> Can Emacs use freopen?

That's not the problem.  The problem is that stderr is used when Emacs
is run in non-interactive mode, and should not be touched then.  The
problem is in detecting when stderr is closed or an invalid handle to
begin with, and do the redirection only then.  In all my readings and
tests, I was unable to find a reliable, let alone documented, way of
determining that.  I don't even know if the "invalid handle" (which is
a pointer on Windows) is NULL or an INVALID_HANDLE_VALUE.

> For example, the following code would do the job on a POSIX
> platform: if stderr is closed, it redirects it to emacs-stderr.txt
> in the current directory, if possible.  Would this sort of thing
> work on Microsoft platform?

It will surely break -batch.  And guess what happens with this
redirection when Emacs has its stderr closed or invalid in the first
place.

Message #97 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 12908 <at> debbugs.gnu.org
Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 20:40:08 -0800

> > That has been my point from the beginning: I don't really care where
> > you stick it, as long as it is in some Emacs/system internal program
> > folder and not a user folder.
> 
> On Unix, the data winds up in some directory under user's home
> directory.  See the manual.

I don't care what Emacs does on Unix or on Windows.  Or on Peanut Butter.  See
the manual - sheesh.  If Emacs on Unix is just as user-inconsiderate in this
regard as it is on Windows, then it too needs to be sent back for regrooving.

My point is the same: Please do not plop such a file into a user folder.  On any
platform.  It does not belong there.  I just happen to be using Emacs on
Windows, and I reported this problem there.  If it is not Windows-specific, fine
- please fix it wherever it occurs.

You are discussing implementation and platforms, as well you should, no doubt.
But my concern is at the user level.  Please don't mess with user data.  That's
not nice.  And this includes user folders containing user files.

I really don't care about the finger-pointing.  You apparently claim that there
is as much of this problem on Unix as on Windows.  Some others seem to disagree
(though that's not too clear to me).

That does not matter to me.  If there is a problem on platform XYZ, please fix
it on XYZ.  For all XYZ, preferably.  For Windows, at least.

It does not sound like a great argument to say that this will not be fixed on
Windows until someone agrees to fix it on Unix also.  Especially if those who
would presumably be the ones to fix it on Unix do not seem to agree that it is a
problem on Unix (again, I'm not sure that's what the claim is).

IOW, here we go 'round & 'round again.  Musical chairs with a bit of blame game
thrown in, it seems.

I hope the bug gets fixed.  On Windows, at least, this is a regression: Users
have never before had to put up with this Emacs pollution of user folders.
Introducing a regression and then classifying it as `wont-fix' is disingenuous.

Please just restore the state before the regression if you cannot find a good
way to fix the bug and still get the backtrace info you want.  Restore the sane
state while you go on to discuss possible ways to deal with the problem in a
ideal way.  If you never find that ideal way, then leave things as they were
before.

I really do not agree with freewheeling introduction of "improvements" that are
accompanied by regressions or other negative behavior that is then classified as
`wont-fix'.  Be less interested in your creative development than in the
possible harm/annoyance to users of its side effects.

The first rule should be not to do any harm.  The second rule should be that if
you accidentally do some harm while trying to improve something, then undo the
harm.

We have users jump through 39 questions/confirmations just to send a bug-report
message or exit without saving a buffer.  Nice and careful, respectful of user
wishes.  And yet here we are now writing crap to user folders without so much as
a "Do you really want to...?" - or even a "Hey, I just wrote some crap to your
folder XYZ - sorry about that!"

Message #100 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12908 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 21:19:02 -0800

On 11/17/2012 07:58 PM, Eli Zaretskii wrote:
> On Unix, the data winds up in some directory under user's home
> directory.

No, on Unix that data is sent to the standard error stream.
This is documented in the manual.

It's common that stderr is redirected to a file,
but it's also common that it's not.  Traditionally
it's not, and many people commonly run Emacs that way.

Message #103 received at 12908 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12908 <at> debbugs.gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sat, 17 Nov 2012 21:19:36 -0800

On 11/17/2012 08:04 PM, Eli Zaretskii wrote:
> The
> problem is in detecting when stderr is closed or an invalid handle to
> begin with, and do the redirection only then.  In all my readings and
> tests, I was unable to find a reliable, let alone documented, way of
> determining that.

The method I gave in <http://bugs.gnu.org/12908#73>
is portable to GNU and POSIXish hosts, where you can test whether
a file descriptor FD is valid by invoking dup2 (FD, FD).
Gnulib has a dup2 implementation that works on Microsoft Windows,
so if we use that, it seems we should be able to use the same idea
there too.

Message #106 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Achim Gratz <Stromeko <at> nexgo.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'?
Date: Sun, 18 Nov 2012 08:08:47 +0100

Eli Zaretskii writes:
> On Unix, the data winds up in some directory under user's home
> directory.  See the manual.

That happens only if STDERR is redirected to a file, which is indeed
commonly the case when a wrapper script starts Emacs on a GUI.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.