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

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

[Drew Adams]

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@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'
 

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

[Juanma Barranquero]

On Fri, Nov 16, 2012 at 7:30 PM, Drew Adams <drew.adams@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@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

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

[Eli Zaretskii]

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

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

[Drew Adams]

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

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

[Drew Adams]

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

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.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 16 Nov 2012 11:08:16 -0800
> Cc: 12908@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.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Drew Adams]

Please do not write such files willy nilly to the directory where the
Emacs process was opened (or whatever).  That is not user-friendly.
 
Please let users decide where to write such files.  Consider even giving
them the option to prevent Emacs from writing such files altogether
(short of giving up using Emacs completely).
 
If such user control is not possible, then please confine such files to
somewhere under .emacs.d or some other "hidden" directory that is
typically far from the files that a user accesses using Emacs or other
applications.
 
Users do not want program-debugging information written to their folder
of family vacation photos or their favorite lasagna recipes.
 
Think _user_.  Emacs is about users.

In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-11-05 on MS-W7-DANI
Bzr revision: 110809 lekktu@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'
 

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

[Drew Adams]

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

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

[Drew Adams]

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

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written

[Drew Adams]

Please see bug #12908 for the start of the discussion (some arguments pro/con
etc.).  That might obviate some repetition here.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

> 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

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

[Stefan Monnier]

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

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

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <lekktu@gmail.com>, <12908@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.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 16 Nov 2012 16:19:33 -0500
> Cc: 12911@debbugs.gnu.org
> 
> > 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.

I agree, but we need to decide what to do if this directory is remote,
because invoking file handlers in this situation is not possible.

Also, on Unix, the information is under the home directory, and the
Unix builds don't themselves create any files, but rather reuse
system-wide settings (which AFAIU aren't settable by users).  So I'm
unsure what this means for platforms other than Windows.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Drew Adams <drew.adams@oracle.com>,  lekktu@gmail.com,  12908@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.

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

[Drew Adams]

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

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

[Drew Adams]

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

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Drew Adams]

BTW, just a thought, in ignorance - ignore if not helpful.

The backtrace file, wherever it might be saved: does it get overwritten when
there is a new crash, or is a new version of it created (e.g.
emacs_backtrace.txt~259~)?

In either case, I assume that it would be good for a user to send a bug report
with (at least) the latest such file.

Would it be possible/useful for a new Emacs session to (a) look for such a file,
(b) if found then automatically compose a bug-report message, and (c) ask the
user whether to send it?  And then (d) perhaps optionally delete the file?

IOW, isn't there some easy way for Emacs Dev to get such info semi-automatically
- upon user agreement/confirmation?

Emacs should know where to look for the file, or at least be able to recognize
it if seen by accident.  And Emacs should be able to pick up the latest such
file if there are multiple versions.  Or perhaps it could combine all such files
in a given directory into a single bug report, separating the backtraces and
timestamping them with the file dates.

Just a thought.  Seems like we are expecting users to do things that they might
not know, care, or bother about doing, when some of the more bothersome lifting
for that could perhaps be done automatically by a subsequent Emacs session.

Any such automatic activity must of course be able to be turned off/on by users,
i.e., an option (opt-in or opt-out).

I imagine that you guys have already thought about such things, and perhaps
dismissed the idea, but I thought I'd mention it anyway, just in case.  Again,
ignore if not helpful.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <12911@debbugs.gnu.org>
> Date: Sat, 17 Nov 2012 09:38:10 -0800
> 
> The backtrace file, wherever it might be saved: does it get overwritten when
> there is a new crash, or is a new version of it created (e.g.
> emacs_backtrace.txt~259~)?

On MS-Windows, neither: the new backtrace gets appended to the file.
I don't know what happens on Unix.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Drew Adams]

> > The backtrace file, wherever it might be saved: does it get 
> > overwritten when there is a new crash, or is a new version
> > of it created (e.g. emacs_backtrace.txt~259~)?
> 
> On MS-Windows, neither: the new backtrace gets appended to the file.
> I don't know what happens on Unix.

OK.  Same question though - would it make sense for a subsequent Emacs session,
if it finds the file, to prepare a bug-report message that includes the info in
the file and propose that the user send it?  And perhaps then delete the file?
(All with user approval, of course.)

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

[Paul Eggert]

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.

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

[Eli Zaretskii]

> Date: Sat, 17 Nov 2012 10:45:00 -0800
> From: Paul Eggert <eggert@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.

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

[Paul Eggert]

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.

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

[Eli Zaretskii]

> Date: Sat, 17 Nov 2012 11:29:47 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12908@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.

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

[Paul Eggert]

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

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

[Drew Adams]

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

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

[Drew Adams]

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

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

[Paul Eggert]

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.

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

[Paul Eggert]

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

Stefan's comment <http://bugs.gnu.org/12911#11> was in response to the request
"Please do not write such files willy nilly to the directory where the
Emacs process was opened (or whatever).  That is not user-friendly."
Stefan agreed with the request, and suggested ~/.emacs.d.  However,
the request was about Emacs's behavior on Microsoft Windows.

On GNU and other non-Microsoft platforms, Emacs already satisfies
the request, because it relies on its invoker to specify where
the debugging information will go, and in practice this approach
works reasonably well on these platforms.  Stefan's comment,
in context, does not imply that Emacs should change its behavior
on these platforms.

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

[Paul Eggert]

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.

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

[Eli Zaretskii]

> Date: Sat, 17 Nov 2012 17:19:57 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, 12911@debbugs.gnu.org
> 
> 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
> 
> Stefan's comment <http://bugs.gnu.org/12911#11> was in response to the request
> "Please do not write such files willy nilly to the directory where the
> Emacs process was opened (or whatever).  That is not user-friendly."
> Stefan agreed with the request, and suggested ~/.emacs.d.  However,
> the request was about Emacs's behavior on Microsoft Windows.
> 
> On GNU and other non-Microsoft platforms, Emacs already satisfies
> the request, because it relies on its invoker to specify where
> the debugging information will go, and in practice this approach
> works reasonably well on these platforms.  Stefan's comment,
> in context, does not imply that Emacs should change its behavior
> on these platforms.

Then I guess we should close this bug as "wontfix", because I submit
that Emacs on Windows does the same as on Unix, namely, puts this data
on a file in a random (but documented) location on the disk.

The only way the Windows code will be changed to write the file in
.emacs.d is if the Unix code is changed to do the same.

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

[Eli Zaretskii]

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

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

[Eli Zaretskii]

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

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

[Eli Zaretskii]

> Date: Sat, 17 Nov 2012 13:25:17 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12908@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.

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

[Drew Adams]

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

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

[Paul Eggert]

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.

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

[Paul Eggert]

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.

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

[Achim Gratz]

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

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

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

For the record, here's what the manual says:

  Emacs is not supposed to crash, but if it does, it produces a "crash
  report" prior to exiting.  The crash report is printed to the standard
  error stream.  If Emacs was started from a graphical desktop on a GNU
  or Unix system, the standard error stream is commonly redirected to a
  file such as `~/.xsession-errors', so you can look for the crash report
  there.  On MS-Windows, the crash report is written to a file named
  `emacs_backtrace.txt' in the current directory of the Emacs process, in
  addition to the standard error stream.

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

Nowadays, tradition is shifting towards GUI invocation, so stderr will
be redirected more often than not.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> Date: Sat, 17 Nov 2012 21:19:36 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12908@debbugs.gnu.org
> 
> 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.

Thanks, but no, thanks.  Gnulib's dup2 implementation uses so many
non-trivial interfaces (exceptions, invalid parameter handlers, etc.)
that I'd prefer not to deal with for a feature that needs to be rock
solid and dependable.

In any case, this is an almost orthogonal issue to what is being
discussed here.  The issue here is not _whether_ to redirect stderr,
but rather _where_to_ to redirect it.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <eggert@cs.ucla.edu>, <12908@debbugs.gnu.org>
> Date: Sat, 17 Nov 2012 20:40:08 -0800
> 
> I don't care what Emacs does on Unix or on Windows.

Well, I do.  Which is why I'm working on developing and maintaining
Emacs.  And if you think that declaring your indifference to the
cross-platform compatibility of Emacs raises the value of your
arguments in my eyes, then I suggest that you reconsider.

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

Any folder on Windows can contain user data, because most Windows
users are usually local administrators and have almost unlimited
privileges (except perhaps on corporate servers).  In fact, Windows
doesn't even have a firm notion of a home directory.  There are
guidelines where _applications_ should put their files, but nothing
about what is "home" for the user, where the user should keep her
precious lasagna recipes.  We (Emacs) pick up one or 2 plausible
locations and pretend they are that "home", but they aren't, as far as
the OS and the rest of applications are concerned.  They are just more
or less random directories.

> The first rule should be not to do any harm.

You are making a mount out of a molehill.  There is no harm.
Well-behaving applications write to all kinds of directories all the
time, including user home directories.  Bash writes ~/.bash_history,
Bazaar writes ~/.bzr.log, Eshell writes ~/.eshell/*.  Etc. etc. --
this is the norm, not the exception.  Emacs behaves according to
well-established norms.

I agree that putting that file in ~/.emacs.d/ (also in the home a
directory, so maybe you will still protest) is slightly better.  But
if Emacs should do that, it should do it on all the supported
platforms.  I'm sorry, but unless this is what's agreed soon, I _will_
close this bug.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Drew Adams]

> > I don't care what Emacs does on Unix or on Windows.
> 
> Well, I do.  Which is why I'm working on developing and maintaining
> Emacs.  

Read my statement in context.  Taking it out of context reverses the intended
meaning.

> And if you think that declaring your indifference to the
> cross-platform compatibility of Emacs

I did no such thing.  I am not at all indifferent to cross-platform
compatibility.  As you know full well.

> raises the value of your arguments in my eyes, then I
> suggest that you reconsider.
> 
> > 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.
> 
> Any folder on Windows can contain user data, because most Windows
> users are usually local administrators and have almost unlimited
> privileges (except perhaps on corporate servers).

Don't make the perfect the enemy of the good.  You are stretching things.

Yes, what you say is true.  No, it is not particularly relevant.  Yes, my entire
C:/ drive is my drive and my data.  So what?  Irrelevant to the discussion.
Please stick to the particulars.

> In fact, Windows
> doesn't even have a firm notion of a home directory.  There are
> guidelines where _applications_ should put their files, but nothing
> about what is "home" for the user, where the user should keep her
> precious lasagna recipes.  We (Emacs) pick up one or 2 plausible
> locations and pretend they are that "home", but they aren't, as far as
> the OS and the rest of applications are concerned.  They are just more
> or less random directories.

I have no argument with any of what you said there.

> > The first rule should be not to do any harm.
> 
> You are making a mount out of a molehill.  There is no harm.
> Well-behaving applications write to all kinds of directories all the
> time, including user home directories.  Bash writes ~/.bash_history,
> Bazaar writes ~/.bzr.log, Eshell writes ~/.eshell/*.  Etc. etc. --
> this is the norm, not the exception.  Emacs behaves according to
> well-established norms.
> 
> I agree that putting that file in ~/.emacs.d/ (also in the home a
> directory, so maybe you will still protest) is slightly better.

Why would I protest?  I'm the one who _suggested_ putting it there.

And I have not once mentioned "home" directory in this discussion.  Perhaps you
are confusing me with someone else.

Anyway, I'm very glad you agree about ~/.emacs.d/.  So at the very least this
bug should remain open on the wishlist until fixed.

To me, this bother is a regression, as I said earlier.  But whether you look at
it like that or not, at least you agree that it is better to put the file in
~/.emacs.d/.  That's progress.

> But if Emacs should do that, it should do it on all the
> supported platforms.  I'm sorry, but unless this is what's
> agreed soon, I _will_ close this bug.

I have no problem with the bug being fixed on all platforms.  In fact, I have
explicitly said (several times now) that if this is also a problem on other
platforms then it _should_ be fixed there as well.

And in the very mail which you quoted out of context above, reversing the sense
of what I wrote!  This is what I said:

 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.

And:

 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.

Pretty damn clear, no?  And this:

 If there is a problem on platform XYZ, please fix it on XYZ.
 For all XYZ, preferably.  For Windows, at least.

Is this problem a mountain or a mole hill?  Closer to the latter, clearly.  But
Emacs users never had this bother before.  Why should they have it now?

Just because on MS Windows everything belongs to the user is no excuse to start
polluting arbitrary folders.  Such an argument is way off-base.

A family who does not (or even cannot) lock their front door is not _asking_ you
to come in and trash their house.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Paul Eggert]

On 11/18/2012 09:16 AM, Eli Zaretskii wrote:
> The issue here is not _whether_ to redirect stderr,
> but rather _where_to_ to redirect it.

On GNU and Unix hosts, there's no issue.
stderr should not be redirected.  It never has
been redirected, and there's no reason to change.

> ... putting that file in ~/.emacs.d/ (also in the home a
> directory, so maybe you will still protest) is slightly better.
> But if Emacs should do that, it should do it on all the supported
> platforms.

There's no reason for Emacs to change its behavior
on GNUish hosts.  People on these hosts are used to
the current behavior with stderr.  Any problems
in this area are limited to Microsoft platforms, and
can be solved in a Microsoft-specific way.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> Date: Sun, 18 Nov 2012 11:18:29 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12911@debbugs.gnu.org
> 
> There's no reason for Emacs to change its behavior
> on GNUish hosts.  People on these hosts are used to
> the current behavior with stderr.  Any problems
> in this area are limited to Microsoft platforms, and
> can be solved in a Microsoft-specific way.

There are no problems on Windows, either.

Bug closed.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

>> There's no reason for Emacs to change its behavior
>> on GNUish hosts.  People on these hosts are used to
>> the current behavior with stderr.  Any problems
>> in this area are limited to Microsoft platforms, and
>> can be solved in a Microsoft-specific way.
> There are no problems on Windows, either.

There's clearly a problem: creating a file emacs_backtrace.txt in some
"in your face" directory annoys some users (and I'm sure we can come up
with funny hypothetical scenarios where it leads to serious breakage of
god knows what).
Hence the suggestion to use ~/.emacs.d which is much less "in your face"
and much safer.


        Stefan "Boy do I wish we never moved away from plain macros"

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

>> > 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.
> I agree, but we need to decide what to do if this directory is remote,
> because invoking file handlers in this situation is not possible.

The file name should be passed straight to the OS without going through
file-name-handlers.  If the OS thinks the directory doesn't exit: no
big deal!

> Also, on Unix, the information is under the home directory, and the
> Unix builds don't themselves create any files, but rather reuse
> system-wide settings (which AFAIU aren't settable by users).  So I'm
> unsure what this means for platforms other than Windows.

No need to change anything on platforms where stderr works.


        Stefan

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: eliz@gnu.org,  drew.adams@oracle.com
> Date: Sun, 18 Nov 2012 20:44:23 -0500
> 
> >> There's no reason for Emacs to change its behavior
> >> on GNUish hosts.  People on these hosts are used to
> >> the current behavior with stderr.  Any problems
> >> in this area are limited to Microsoft platforms, and
> >> can be solved in a Microsoft-specific way.
> > There are no problems on Windows, either.
> 
> There's clearly a problem: creating a file emacs_backtrace.txt in some
> "in your face" directory annoys some users (and I'm sure we can come up
> with funny hypothetical scenarios where it leads to serious breakage of
> god knows what).
> Hence the suggestion to use ~/.emacs.d which is much less "in your face"
> and much safer.

I'm waiting for this to be implemented on Posix platforms, then.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: drew.adams@oracle.com,  12911@debbugs.gnu.org
> Date: Sun, 18 Nov 2012 20:52:43 -0500
> 
> No need to change anything on platforms where stderr works.

stderr works on Windows as well.  See the code I wrote.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

>> No need to change anything on platforms where stderr works.
> stderr works on Windows as well.  See the code I wrote.

If stderr works, then why do we need emacs_backtrace.txt?


        Stefan

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: drew.adams@oracle.com,  12911@debbugs.gnu.org
> Date: Sun, 18 Nov 2012 23:07:25 -0500
> 
> >> No need to change anything on platforms where stderr works.
> > stderr works on Windows as well.  See the code I wrote.
> 
> If stderr works, then why do we need emacs_backtrace.txt?

For when the stuff written to stderr ends up in the Great Void, or
scrolls off the screen, or whatever.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

>> >> No need to change anything on platforms where stderr works.
>> > stderr works on Windows as well.  See the code I wrote.
>> If stderr works, then why do we need emacs_backtrace.txt?
> For when the stuff written to stderr ends up in the Great Void, or
> scrolls off the screen, or whatever.

Right.  That's what I meant by "stderr doesn't work" (IOW while it does
work in some cases, it can't be relied upon).

So let me reword my suggestion:

  I suggested to change the code such that, in those cases where we need
  to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead.


        Stefan

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org
> Date: Mon, 19 Nov 2012 13:04:20 -0500
> 
> >> >> No need to change anything on platforms where stderr works.
> >> > stderr works on Windows as well.  See the code I wrote.
> >> If stderr works, then why do we need emacs_backtrace.txt?
> > For when the stuff written to stderr ends up in the Great Void, or
> > scrolls off the screen, or whatever.
> 
> Right.  That's what I meant by "stderr doesn't work" (IOW while it does
> work in some cases, it can't be relied upon).

But then your first sentence above applies not only to Windows,
because stderr "doesn't work" in this sense on Unix as well.

> So let me reword my suggestion:
> 
>   I suggested to change the code such that, in those cases where we need
>   to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead.

I already agreed to this, provided that Emacs puts stderr output there
on all platforms.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

>> >> >> No need to change anything on platforms where stderr works.
>> >> > stderr works on Windows as well.  See the code I wrote.
>> >> If stderr works, then why do we need emacs_backtrace.txt?
>> > For when the stuff written to stderr ends up in the Great Void, or
>> > scrolls off the screen, or whatever.
>> Right.  That's what I meant by "stderr doesn't work" (IOW while it does
>> work in some cases, it can't be relied upon).
> But then your first sentence above applies not only to Windows,
> because stderr "doesn't work" in this sense on Unix as well.

I don't know of any case under Unix where stderr is dumped into the
great void (except for cases where the user would then also want the
backtrace to be dumped in that great void).

>> So let me reword my suggestion:
>> I suggested to change the code such that, in those cases where we need
>> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead.
> I already agreed to this, provided that Emacs puts stderr output there
> on all platforms.

Yes, on all platforms where emacs_backtrace.txt is needed (in practice,
this does reduce to w32, AFAIK).


        Stefan

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org
> Date: Mon, 19 Nov 2012 13:35:15 -0500
> 
> >> >> >> No need to change anything on platforms where stderr works.
> >> >> > stderr works on Windows as well.  See the code I wrote.
> >> >> If stderr works, then why do we need emacs_backtrace.txt?
> >> > For when the stuff written to stderr ends up in the Great Void, or
> >> > scrolls off the screen, or whatever.
> >> Right.  That's what I meant by "stderr doesn't work" (IOW while it does
> >> work in some cases, it can't be relied upon).
> > But then your first sentence above applies not only to Windows,
> > because stderr "doesn't work" in this sense on Unix as well.
> 
> I don't know of any case under Unix where stderr is dumped into the
> great void

It can still scroll off the screen.  Or end up in some file that the
window-system developers or admins set up, and that is some random or
unknown place, as far as Emacs users and maintainers are concerned.  I
see no significant difference.

> >> So let me reword my suggestion:
> >> I suggested to change the code such that, in those cases where we need
> >> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead.
> > I already agreed to this, provided that Emacs puts stderr output there
> > on all platforms.
> 
> Yes, on all platforms where emacs_backtrace.txt is needed (in practice,
> this does reduce to w32, AFAIK).

No, on _all_ platforms.

But I'm repeating myself.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

>> I don't know of any case under Unix where stderr is dumped into the
>> great void
> It can still scroll off the screen.  Or end up in some file that the
> window-system developers or admins set up, and that is some random or
> unknown place, as far as Emacs users and maintainers are concerned.
> I see no significant difference.

The difference is that the above cases are hypothetical, whereas the w32
case is the norm.

>> >> So let me reword my suggestion:
>> >> I suggested to change the code such that, in those cases where we need
>> >> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead.
>> > I already agreed to this, provided that Emacs puts stderr output there
>> > on all platforms.
>> Yes, on all platforms where emacs_backtrace.txt is needed (in practice,
>> this does reduce to w32, AFAIK).
> No, on _all_ platforms.

We disagree on the "is needed" part.  I'm not sure that w32 is the only
one where it's needed, but so far the need hasn't cropped up elsewhere.
Maybe macsox needs it as well?


        Stefan

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org
> Date: Mon, 19 Nov 2012 14:47:26 -0500
> 
> >> I don't know of any case under Unix where stderr is dumped into the
> >> great void
> > It can still scroll off the screen.  Or end up in some file that the
> > window-system developers or admins set up, and that is some random or
> > unknown place, as far as Emacs users and maintainers are concerned.
> > I see no significant difference.
> 
> The difference is that the above cases are hypothetical, whereas the w32
> case is the norm.

Neither is correct.  I just had the backtrace on GNU/Linux scroll off
on me (a TTY session crashed).  And I almost always invoke Emacs on
Windows in a way that leaves stderr output around.

But that is besides the point.  For J.R. Hacker who reads the manual,
what matters is what happens on her machine, not the statistical
average.  And what happens on her machine could well be that stderr
ends up in some random place on her disk.  As long as that is a real
possibility, writing emacs_backtrace.txt in the directory it is
written now on Windows is equivalent to what happens on Unix.  Making
it in ~/.emacs.d on w32 alone doesn't change the basic fact that most
of the users we care about will still have their backtraces in random
places.  Why not change that on all platforms?  Why demand that only
of w32?  For that matter, why do you care so much about w32 users?

> >> >> So let me reword my suggestion:
> >> >> I suggested to change the code such that, in those cases where we need
> >> >> to use emacs_backtrace.txt, we use ~/.emacs.d/backtrace.txt instead.
> >> > I already agreed to this, provided that Emacs puts stderr output there
> >> > on all platforms.
> >> Yes, on all platforms where emacs_backtrace.txt is needed (in practice,
> >> this does reduce to w32, AFAIK).
> > No, on _all_ platforms.
> 
> We disagree on the "is needed" part.

No, we disagree about the importance of uniformity in operation across
platforms.  Either the data is in a platform-specific place, in which
case the current arrangement is as good as any, or it is in the same
Emacs-specific place on all platforms.  The latter is the arrangement
I'd support and it will give me enough motivation to spend more effort
on this (although I'm not sure I have any energy left after this
longish discussion).

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

> Making it in ~/.emacs.d on w32 alone doesn't change the basic fact
> that most of the users we care about will still have their backtraces
> in random places.

No, ~/.xsesson-errors is not a random place.  Even if the user doesn't
know it, we do.

> Why not change that on all platforms?

Because stderr is good enough under GNU/Linux (and it's easy to
redirect when it matters).

> Why demand that only of w32?

Because currently w32 users get annoyed with new files appearing where
they don't want any.  If you prefer to always send it to stderr under
Windows, please do so, I really couldn't care less if that means it's
usually sent to /dev/null.

> No, we disagree about the importance of uniformity in operation across
> platforms.

I suggested above another way to be uniform across platforms.

> Either the data is in a platform-specific place, in which
> case the current arrangement is as good as any,

No, writing to an arbitrary file in the current directory is not
a good arrangement.
I personally don't care whether it's uniform across platforms or not.

I didn't like the backtrace business to start with and am finding it
worse by the day.  And it doesn't even give me the info that the old
"assert in a macro" gave me.


        Stefan

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: drew.adams@oracle.com, 12911@debbugs.gnu.org
> Date: Mon, 19 Nov 2012 16:15:17 -0500
> 
> > Making it in ~/.emacs.d on w32 alone doesn't change the basic fact
> > that most of the users we care about will still have their backtraces
> > in random places.
> 
> No, ~/.xsesson-errors is not a random place.  Even if the user doesn't
> know it, we do.

This place is also platform-specific.  Not on every Posix platform
stderr is put there.

> > Why not change that on all platforms?
> 
> Because stderr is good enough under GNU/Linux (and it's easy to
> redirect when it matters).

And the current arrangement on Windows is good enough for that system.

> > Why demand that only of w32?
> 
> Because currently w32 users get annoyed with new files appearing where
> they don't want any.

Only one user complained so far.

> If you prefer to always send it to stderr under Windows, please do
> so, I really couldn't care less if that means it's usually sent to
> /dev/null.

Well, I do care, so I wrote the code to be better than that.

> No, writing to an arbitrary file in the current directory is not
> a good arrangement.

I disagree, obviously.

> I didn't like the backtrace business to start with and am finding it
> worse by the day.

Should I say "told you so"?

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

>> Because currently w32 users get annoyed with new files appearing where
>> they don't want any.
> Only one user complained so far.

FWIW, I'd be annoyed if I were a w32 user and had to deal with
emacs_backtrace.txt files appearing in directories without my saying
so explicitly.


        Stefan

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

On 11/19/2012 8:59 PM, Stefan Monnier wrote:
>>> Because currently w32 users get annoyed with new files appearing where
>>> they don't want any.
>> Only one user complained so far.
> 
> FWIW, I'd be annoyed if I were a w32 user and had to deal with
> emacs_backtrace.txt files appearing in directories without my saying
> so explicitly.

I agree that the behavior is bad. If we really need these emacs_backtrace.txt,
they should go under %LOCALAPPDATA%.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Andy Moreton]

On Tue 20 Nov 2012, Daniel Colascione wrote:

> On 11/19/2012 8:59 PM, Stefan Monnier wrote:
>>>> Because currently w32 users get annoyed with new files appearing where
>>>> they don't want any.
>>> Only one user complained so far.
>> 
>> FWIW, I'd be annoyed if I were a w32 user and had to deal with
>> emacs_backtrace.txt files appearing in directories without my saying
>> so explicitly.
>
> I agree that the behavior is bad. If we really need these emacs_backtrace.txt,
> they should go under %LOCALAPPDATA%.

Given that the backtrace does not include symbols, it seems fairly
useless to me. I'd vote for getting rid of it on all platforms.

    AndyM

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Tue, 20 Nov 2012 13:16:18 +0000
> 
> Given that the backtrace does not include symbols, it seems fairly
> useless to me. I'd vote for getting rid of it on all platforms.

I'd be the last to defend the feature, but out of fairness: symbolic
information (i.e. file names and source line numbers) are one command
away.  See the manual for details.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Juanma Barranquero]

On Tue, Nov 20, 2012 at 5:59 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> FWIW, I'd be annoyed if I were a w32 user and had to deal with
> emacs_backtrace.txt files appearing in directories without my saying
> so explicitly.

Windows binaries for official releases (as opposed to trunk snapshots)
rarely crash. It's not as if the user is going to get backtraces all
over his hard disk on every single run.

    Juanma

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> Date: Mon, 19 Nov 2012 21:02:22 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: Eli Zaretskii <eliz@gnu.org>, 12911@debbugs.gnu.org
> 
> On 11/19/2012 8:59 PM, Stefan Monnier wrote:
> >>> Because currently w32 users get annoyed with new files appearing where
> >>> they don't want any.
> >> Only one user complained so far.
> > 
> > FWIW, I'd be annoyed if I were a w32 user and had to deal with
> > emacs_backtrace.txt files appearing in directories without my saying
> > so explicitly.
> 
> I agree that the behavior is bad. If we really need these emacs_backtrace.txt,
> they should go under %LOCALAPPDATA%.

Maybe you guys think I've decided to put the file in the current
directory without any thought, just because I find it easier not to
futz with leading directories.  That's far from being true.  I did
invest some thought and a bit of research before making a decision.

Look, we are talking about emergency measures.  Not some normal
feature that writes files as a matter of habit.  Emacs is going down
in flames, and we want at the last moment to get some information from
it.  Code that does that must be as simple and as reliable as
possible, or it will not work, or, worse, cause nested exceptions that
will completely obscure the original cause.

%LOCALAPPDATA%?  It doesn't exist on XP and earlier systems.  There's
only %APPDATA% there.  To distinguish, we'd need to probe the OS
version, or try both places.  That means more system API calls.  Not
rocket science, but still: complications, at the time that every tweak
counts.

(Incidentally, %APPDATA% is what we by default treat as HOME, a
directory that I'm told is full of lasagna recipes we are not allowed
to contaminate.)

Accessing environment variables is another problematic place.  We are
crashing, so the heap or the whole arena can be trashed.  Who can be
sure the environment variables will not point to garbled places?

And what if the %LOCALAPPDATA% doesn't exist as an environment
variable?  We'd need to access the Registry.  More complications and
API calls.

Someone else suggested to write into the directory where the Emacs
binary is installed.  But latest Windows versions make the directory
where programs are installed write-protected, especially if the user
has Administrator privileges.  Worse, there's this thing called
"filesystem virtualization", whereby the program is allowed to write
to those directories, but the data is actually redirected into some
hidden directory no one can find, even if they know about this.

Etc., etc.  Yes, the current directory is far from ideal.  But on
balance, I find it the lesser evil, and my long experience on
MS-Windows tells me that it is still the best choice for data you must
reliably write somewhere.

(Of course, Stefan says that he doesn't care if the data is lost, so
all of the above doesn't matter to him.  But, as long as we have this
feature, I _do_ care, otherwise I wouldn't have sit down and written
it.  Arguments whose authors don't care cannot possibly convince me.
If we _really_ don't care, let's go ahead and rip out the whole
feature.  That'd be at least honest.)

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written

[Drew Adams]

> > FWIW, I'd be annoyed if I were a w32 user and had to deal with
> > emacs_backtrace.txt files appearing in directories without my saying
> > so explicitly.
> 
> Windows binaries for official releases (as opposed to trunk snapshots)
> rarely crash. It's not as if the user is going to get backtraces all
> over his hard disk on every single run.

FWIW, that is not my experience, not with Emacs 24.

Official Emacs binaries 24.1 and 24.2 crash for me, seemingly randomly, sooner
or later, pretty much each time I use them - and I don't get to use them for
long.  If I had a recipe I would send it along.  I sent an emacs-backtrace.txt
file recently, which Eli said should be useful, but no news yet on whether it
helped fix some bug. ;-)

I agree, however, that a user is not going to be getting backtraces all over the
place.  That's some consolation, but not reason enough by itself to introduce
this regression, IMHO (just one opinion).

As Eli himself said - and was the first to point out AFAIK
(http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00501.html):

EZ> Based on my experience, I expect this "feature" to be hated,
EZ> by users and Emacs maintainers alike.

I think he's likely to be right in that guess.  And he points out several
reasons against introducing this feature (reasons I'm not qualified to judge).

Eli also said, there:
EZ> using the limited information it provides can be quite difficult

Whether the feature is worth the various drawbacks mentioned, I, for one, cannot
say.

But it sure would be good to find a way to put these backtrace files somewhere
other than a user folder.  That I will say.

FWIW, both Emacs maintainers have seemed to agree.  Yidong said this
(http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00870.html):

CY> Littering the filesystem with these backtrace files is
CY> kind of obnoxious.

Certainly, plopping them into user folders is.  User data is not for Emacs to
fiddle with uninvited, and that includes folders.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]

On 11/20/12 9:03 AM, Eli Zaretskii wrote:
>> Date: Mon, 19 Nov 2012 21:02:22 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: Eli Zaretskii <eliz@gnu.org>, 12911@debbugs.gnu.org
>>
>> On 11/19/2012 8:59 PM, Stefan Monnier wrote:
>>>>> Because currently w32 users get annoyed with new files appearing where
>>>>> they don't want any.
>>>> Only one user complained so far.
>>>
>>> FWIW, I'd be annoyed if I were a w32 user and had to deal with
>>> emacs_backtrace.txt files appearing in directories without my saying
>>> so explicitly.
>>
>> I agree that the behavior is bad. If we really need these emacs_backtrace.txt,
>> they should go under %LOCALAPPDATA%.
> 
> %LOCALAPPDATA%?  It doesn't exist on XP and earlier systems.  There's
> only %APPDATA% there.  To distinguish, we'd need to probe the OS
> version, or try both places.  That means more system API calls.  Not
> rocket science, but still: complications, at the time that every tweak
> counts.
> Accessing environment variables is another problematic place.
> And what if the %LOCALAPPDATA% doesn't exist as an environment
> variable?  We'd need to access the Registry.

Compute the name of the backtrace file when Emacs starts. A crash is
unlikely to corrupt a single allocation.

> (Incidentally, %APPDATA% is what we by default treat as HOME, a
> directory that I'm told is full of lasagna recipes we are not allowed
> to contaminate.)

%USERPROFILE% is where I put my lasagna recipes. %APPDATA% is full of
non-user-visible application data on my system. Is %APPDATA% actually
a user-visible directory of some sort on XP?

> We are
> crashing, so the heap or the whole arena can be trashed.  Who can be
> sure the environment variables will not point to garbled places?

A process cannot reliably report all of its own crashes. That's why
Windows Error Reporting monitors processes with a service and collects
dumps of crashing processes from outside, in a separate process.
Collecting information about most crashes is adequate.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 20 Nov 2012 17:36:50 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, 12911@debbugs.gnu.org
> 
> It's not as if the user is going to get backtraces all over his hard
> disk on every single run.

"All over the hard disk" will almost never happen, because people who
invoke Emacs from a desktop icon will always have Emacs run in the
same directory.  All the backtraces will be on a single file in that
directory.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 20 Nov 2012 09:11:46 -0800
> Cc: 12911@debbugs.gnu.org
> 
> I sent an emacs-backtrace.txt file recently

Where?  I must have missed that, or maybe forgot.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> Date: Tue, 20 Nov 2012 09:36:36 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: monnier@iro.umontreal.ca, 12911@debbugs.gnu.org
> 
> Compute the name of the backtrace file when Emacs starts.

Sorry, as long as this is a Windows-specific issue, I don't have any
motivation to go to that length.

> > (Incidentally, %APPDATA% is what we by default treat as HOME, a
> > directory that I'm told is full of lasagna recipes we are not allowed
> > to contaminate.)
> 
> %USERPROFILE% is where I put my lasagna recipes. %APPDATA% is full of
> non-user-visible application data on my system.

That's another sign of what I said earlier: there's no home directory
on Windows.  Yet another candidate is "My Documents" (e.g., bzr uses
it).  But none of them is really for the user, according to Windows
guidelines.

> Is %APPDATA% actually a user-visible directory of some sort on XP?

Yes.  Each user is the owner of her %APPDATA%, and has full access
rights.  That directory is for applications to put their per-user
data.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written

[Drew Adams]

> > I sent an emacs-backtrace.txt file recently
> 
> Where?  I must have missed that, or maybe forgot.

The first mail that started this discussion:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12908

This is the exchange we had about it:

EZ>>>> Users should include it with their bug reports.
DA>>> 
DA>>> Does my having included it in this bug report help in some
DA>>> way?  I'm guessing no, but would love to be shown wrong.
EZ>>
EZ>> Your guess is wrong, that file includes enough information
EZ>> to understand where the crash happened, and in some cases
EZ>> also why.
DA>
DA> That's good news.  Let's hope it helps fix some of the
DA> crashing problems.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <lekktu@gmail.com>, <monnier@iro.umontreal.ca>, <12911@debbugs.gnu.org>
> Date: Tue, 20 Nov 2012 10:10:30 -0800
> 
> > > I sent an emacs-backtrace.txt file recently
> > 
> > Where?  I must have missed that, or maybe forgot.
> 
> The first mail that started this discussion:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12908

Thanks.

Dani, where can I find the binary which fits this:

  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'

Or maybe you (Dani) can run addr2line on that binary and tell what you
get from Drew's backtraces.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

> Accessing environment variables is another problematic place.  We are
> crashing, so the heap or the whole arena can be trashed.  Who can be
> sure the environment variables will not point to garbled places?

Just to put things in perspective: this backtrace "feature" was put in
to replace/supplement the previous assertion failure output (because
with asserts now being inside inlinable functions, the line&file info
we get is not the one we want any more).  So the environment is usually
still pretty sane, because assertions are usually caught fairly early.

Of course, there will be cases where the process is sufficiently botched
up that we can't build the file name ~/.emacs.d/backtrace.txt, while we
might still be able to just use "backtrace.txt" successfully, but
I don't think those borderline cases are sufficiently common to be
worry about them.


        Stefan

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Daniel Colascione <dancol@dancol.org>, 12911@debbugs.gnu.org
> Date: Tue, 20 Nov 2012 13:30:52 -0500
> 
> > Accessing environment variables is another problematic place.  We are
> > crashing, so the heap or the whole arena can be trashed.  Who can be
> > sure the environment variables will not point to garbled places?
> 
> Just to put things in perspective: this backtrace "feature" was put in
> to replace/supplement the previous assertion failure output (because
> with asserts now being inside inlinable functions, the line&file info
> we get is not the one we want any more).  So the environment is usually
> still pretty sane, because assertions are usually caught fairly early.

If the backtrace is created due to assertion violation, yes.  But it
is also invoked for all the other fatal signals.

bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written

[Drew Adams]

> Yet another candidate is "My Documents" (e.g., bzr uses
> it).  But none of them is really for the user, according to Windows
> guidelines.

Really?  I don't know (or care too much) what Windows guidelines might say about
this.  But I would be mildly curious about that, if you happen to have a URL.

Everyone I know considers `My Documents' and its subfolders to be a user folder
- maybe even *THE* user folder par excellence.

There is even a `My Documents' folder for each user defined for the machine.
(Another name for it can be Administrator's Documents, Drew's Documents, Eli's
Documents. etc.)  Pretty clear to me that this intended to separate one users
documents from those of another user, as well as from non-user documents.

Why any program (e.g. bzr, apparently) would want to consider that folder as
fair game for stuffing its internal stuff is beyond me.  How impolite.

Anyway, let's see what good ol' Wikipedia has to say...
http://en.wikipedia.org/wiki/My_Documents

 My Documents is the name of a special folder on the computer's
 hard drive that the system commonly uses to store a user's
 documents, music, pictures, downloads, and other files.

Whaddya know?  And it says `My Documents' was introduced, "as a standard
location for storing user-created files."

Hm.  That all sounds just like what I think about it.  And about its subfolders,
including `My Music',...  That "My" should tell us something, I would think.

`My Documents' is not the kind of place a civilized program would want to
pollute with its own crap.

Now of course, installing a program might well create a subfolder under `My
Documents' that is intended for user-created data that is specific to that
program - e.g. music files you save.  Nothing wrong with that.

That is not the same as a place to stuff program-internal data.  We have
`Program Files' and user-specific `Local Settings\Application Data' for that
kind of thing.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

>> > > I sent an emacs-backtrace.txt file recently
>> >
>> > Where?  I must have missed that, or maybe forgot.
>>
>> The first mail that started this discussion:
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12908
>
> Thanks.
>
> Dani, where can I find the binary which fits this:

(I've caught this by chance - I was not in the "to" or the "cc")

You can get the binary from
https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8

The file to pick up is obvious looking at the revno (110809).

>   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'
>
> Or maybe you (Dani) can run addr2line on that binary and tell what you
> get from Drew's backtraces.

I'm never done that, but I've tried it:
   addr2line -e emacs.exe < bt-in.txt > bt-out.txt

where the "emacs.exe" is the one from the build used by Drew. I'm
attaching both files.

HTH.

-- 
Dani Moncayo

[-- Attachment #2: bt-in.txt --]
[-- Type: text/plain, Size: 1752 bytes --]

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

[-- Attachment #3: bt-out.txt --]
[-- Type: text/plain, Size: 4768 bytes --]

??:0
c:\emacs\trunk\src/w32fns.c:7717
c:\emacs\trunk\src/w32fns.c:7749
c:\emacs\trunk\src/emacs.c:345
c:\emacs\trunk\src/alloc.c:6440
c:\emacs\trunk\src/xdisp.c:13540
c:\emacs\trunk\src/xdisp.c:13748
c:\emacs\trunk\src/keyboard.c:2426
c:\emacs\trunk\src/keyboard.c:9223
c:\emacs\trunk\src/keyboard.c:1458
c:\emacs\trunk\src/eval.c:1288
c:\emacs\trunk\src/keyboard.c:1167
c:\emacs\trunk\src/eval.c:1059
c:\emacs\trunk\src/keyboard.c:1146
c:\emacs\trunk\src/keyboard.c:778
c:\emacs\trunk\src/keyboard.c:842
c:\emacs\trunk\src/emacs.c:1564
crt1.c:0
??:0
??:0
??:0
c:\emacs\trunk\src/w32fns.c:7717
c:\emacs\trunk\src/w32fns.c:7749
c:\emacs\trunk\src/emacs.c:345
c:\emacs\trunk\src/alloc.c:6440
c:\emacs\trunk\src/fileio.c:5380
c:\emacs\trunk\src/emacs.c:1941
c:\emacs\trunk\src/emacs.c:329
c:\emacs\trunk\src/alloc.c:6440
c:\emacs\trunk\src/xdisp.c:13909
c:\emacs\trunk\src/xdisp.c:13491
c:\emacs\trunk\src/xdisp.c:12691
c:\emacs\trunk\src/keyboard.c:2428
c:\emacs\trunk\src/keyboard.c:9223
c:\emacs\trunk\src/keyboard.c:1458
c:\emacs\trunk\src/eval.c:1288
c:\emacs\trunk\src/keyboard.c:1167
c:\emacs\trunk\src/eval.c:1059
c:\emacs\trunk\src/keyboard.c:1146
c:\emacs\trunk\src/keyboard.c:778
c:\emacs\trunk\src/keyboard.c:842
c:\emacs\trunk\src/emacs.c:1564
crt1.c:0
??:0
??:0
??:0
c:\emacs\trunk\src/w32fns.c:7717
c:\emacs\trunk\src/w32fns.c:7749
c:\emacs\trunk\src/emacs.c:345
c:\emacs\trunk\src/sysdep.c:1638
c:\emacs\trunk\src/sysdep.c:1614
c:\emacs\trunk\src/sysdep.c:1650
crt1.c:0
??:0
??:0
??:0
c:\emacs\trunk\src/w32fns.c:7717
c:\emacs\trunk\src/w32fns.c:7749
c:\emacs\trunk\src/emacs.c:345
c:\emacs\trunk\src/sysdep.c:1638
c:\emacs\trunk\src/sysdep.c:1614
c:\emacs\trunk\src/sysdep.c:1650
crt1.c:0
??:0
??:0
??:0
c:\emacs\trunk\src/w32fns.c:7717
c:\emacs\trunk\src/w32fns.c:7749
c:\emacs\trunk\src/emacs.c:345
c:\emacs\trunk\src/alloc.c:6440
c:\emacs\trunk\src/fileio.c:5380
c:\emacs\trunk\src/emacs.c:1941
c:\emacs\trunk\src/emacs.c:329
c:\emacs\trunk\src/alloc.c:6440
c:\emacs\trunk\src/textprop.c:467
c:\emacs\trunk\src/textprop.c:1487
c:\emacs\trunk\src/xdisp.c:11613
c:\emacs\trunk\src/xdisp.c:11980
c:\emacs\trunk\src/xdisp.c:16246
c:\emacs\trunk\src/xdisp.c:13932
c:\emacs\trunk\src/eval.c:1326
c:\emacs\trunk\src/xdisp.c:13912
c:\emacs\trunk\src/xdisp.c:13491
c:\emacs\trunk\src/xdisp.c:12691
c:\emacs\trunk\src/keyboard.c:2428
c:\emacs\trunk\src/keyboard.c:9223
c:\emacs\trunk\src/keyboard.c:1458
c:\emacs\trunk\src/eval.c:1288
c:\emacs\trunk\src/keyboard.c:1167
c:\emacs\trunk\src/eval.c:1059
c:\emacs\trunk\src/keyboard.c:1146
c:\emacs\trunk\src/keyboard.c:778
c:\emacs\trunk\src/keyboard.c:842
c:\emacs\trunk\src/emacs.c:1564
crt1.c:0
??:0
??:0
??:0
c:\emacs\trunk\src/w32fns.c:7717
c:\emacs\trunk\src/w32fns.c:7749
c:\emacs\trunk\src/emacs.c:345
c:\emacs\trunk\src/alloc.c:6440
c:\emacs\trunk\src/dispnew.c:1257
c:\emacs\trunk\src/dispnew.c:4239
c:\emacs\trunk\src/dispnew.c:3532
c:\emacs\trunk\src/dispnew.c:3284
c:\emacs\trunk\src/dispnew.c:3213
c:\emacs\trunk\src/xdisp.c:13528
c:\emacs\trunk\src/xdisp.c:12691
c:\emacs\trunk\src/keyboard.c:2428
c:\emacs\trunk\src/keyboard.c:9223
c:\emacs\trunk\src/keyboard.c:1458
c:\emacs\trunk\src/eval.c:1288
c:\emacs\trunk\src/keyboard.c:1167
c:\emacs\trunk\src/eval.c:1059
c:\emacs\trunk\src/keyboard.c:1146
c:\emacs\trunk\src/keyboard.c:778
c:\emacs\trunk\src/keyboard.c:842
c:\emacs\trunk\src/emacs.c:1564
crt1.c:0
??:0
??:0
??:0
c:\emacs\trunk\src/w32fns.c:7717
c:\emacs\trunk\src/w32fns.c:7749
c:\emacs\trunk\src/emacs.c:345
c:\emacs\trunk\src/sysdep.c:1638
c:\emacs\trunk\src/sysdep.c:1614
c:\emacs\trunk\src/sysdep.c:1650
crt1.c:0
??:0
??:0
??:0
c:\emacs\trunk\src/w32fns.c:7717
c:\emacs\trunk\src/w32fns.c:7749
c:\emacs\trunk\src/emacs.c:345
c:\emacs\trunk\src/alloc.c:6440
c:\emacs\trunk\src/fontset.c:1999
c:\emacs\trunk\src/eval.c:2777
c:\emacs\trunk\src/bytecode.c:899
c:\emacs\trunk\src/eval.c:3006
c:\emacs\trunk\src/eval.c:2823
c:\emacs\trunk\src/bytecode.c:899
c:\emacs\trunk\src/eval.c:3006
c:\emacs\trunk\src/eval.c:2823
c:\emacs\trunk\src/bytecode.c:899
c:\emacs\trunk\src/eval.c:3006
c:\emacs\trunk\src/eval.c:2823
c:\emacs\trunk\src/bytecode.c:899
c:\emacs\trunk\src/eval.c:3006
c:\emacs\trunk\src/eval.c:2823
c:\emacs\trunk\src/callint.c:852
c:\emacs\trunk\src/eval.c:2781
c:\emacs\trunk\src/eval.c:2599
c:\emacs\trunk\src/keyboard.c:10233
c:\emacs\trunk\src/keyboard.c:1586
c:\emacs\trunk\src/eval.c:1288
c:\emacs\trunk\src/keyboard.c:1167
c:\emacs\trunk\src/eval.c:1059
c:\emacs\trunk\src/keyboard.c:1146
c:\emacs\trunk\src/keyboard.c:778
c:\emacs\trunk\src/keyboard.c:842
c:\emacs\trunk\src/emacs.c:1564
crt1.c:0
??:0

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written

[Eli Zaretskii]

> Date: Tue, 20 Nov 2012 20:15:10 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>, lekktu@gmail.com, monnier@iro.umontreal.ca, 
> 	12911@debbugs.gnu.org
> 
> > Dani, where can I find the binary which fits this:
> 
> (I've caught this by chance - I was not in the "to" or the "cc")

??? Of course you were in "To", take another look.

> You can get the binary from
> https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8

Thanks.

> > Or maybe you (Dani) can run addr2line on that binary and tell what you
> > get from Drew's backtraces.
> 
> I'm never done that, but I've tried it:
>    addr2line -e emacs.exe < bt-in.txt > bt-out.txt
> 
> where the "emacs.exe" is the one from the build used by Drew. I'm
> attaching both files.

Thanks.

Drew, you really should report these, and try cooperating in the
resolution of these problems.  There are at least 2 crashes here that
I never saw.

> c:\emacs\trunk\src/w32fns.c:7717
> c:\emacs\trunk\src/w32fns.c:7749
> c:\emacs\trunk\src/emacs.c:345
> c:\emacs\trunk\src/alloc.c:6440
> c:\emacs\trunk\src/xdisp.c:13540

This is assertion violation in redisplay_internal, here:

      eassert (EQ (XFRAME (selected_frame)->selected_window,
                   selected_window));

This crash is probably of the kind you reported in the past, related
to the selected-frame/selected-window issues.

> c:\emacs\trunk\src/w32fns.c:7717
> c:\emacs\trunk\src/w32fns.c:7749
> c:\emacs\trunk\src/emacs.c:345
> c:\emacs\trunk\src/alloc.c:6440
> c:\emacs\trunk\src/fileio.c:5380

This is a crash in auto-save, which I never saw before:

  for (do_handled_files = 0; do_handled_files < 2; do_handled_files++)
    for (tail = Vbuffer_alist; CONSP (tail); tail = XCDR (tail))
      {
        buf = XCDR (XCAR (tail));
        b = XBUFFER (buf);    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

> c:\emacs\trunk\src/w32fns.c:7717
> c:\emacs\trunk\src/w32fns.c:7749
> c:\emacs\trunk\src/emacs.c:345
> c:\emacs\trunk\src/alloc.c:6440
> c:\emacs\trunk\src/dispnew.c:1257

Another assertion violation in redisplay:

static bool
row_equal_p (struct glyph_row *a, struct glyph_row *b, bool mouse_face_p)
{
  eassert (verify_row_hash (a));
  eassert (verify_row_hash (b));  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<

> c:\emacs\trunk\src/w32fns.c:7717
> c:\emacs\trunk\src/w32fns.c:7749
> c:\emacs\trunk\src/emacs.c:345
> c:\emacs\trunk\src/alloc.c:6440
> c:\emacs\trunk\src/fontset.c:1999

This crash is in fontset-info:

              /* Then store opened font names to cdr of each elements.  */
              for (i = 0; ! NILP (realized[k][i]); i++)
                {
                  if (c <= MAX_5_BYTE_CHAR)
                    val = FONTSET_REF (realized[k][i], c);
                  else
                    val = FONTSET_FALLBACK (realized[k][i]);
                  if (! CONSP (val) || ! VECTORP (XCDR (val)))
                    continue;
                  /* VAL: (int . [[FACE-ID FONT-DEF FONT-OBJECT int] ... ])  */
                  val = XCDR (val);
                  for (j = 0; j < ASIZE (val); j++)
                    {
                      elt = AREF (val, j);
                      if (FONT_OBJECT_P (RFONT_DEF_OBJECT (elt)))  <<<<<<<<<

I don't think I've ever heard about such crashes.

bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written

[Eli Zaretskii]

> X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
> 	RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.2
> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <12911@debbugs.gnu.org>
> Date: Tue, 20 Nov 2012 10:57:00 -0800
> 
> > Yet another candidate is "My Documents" (e.g., bzr uses
> > it).  But none of them is really for the user, according to Windows
> > guidelines.
> 
> Really?  I don't know (or care too much) what Windows guidelines might say about
> this.  But I would be mildly curious about that, if you happen to have a URL.

  http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx

> Everyone I know considers `My Documents' and its subfolders to be a user folder
> - maybe even *THE* user folder par excellence.

"The file system directory used to physically store a user's common
repository of documents."  What do you make of that?  "User's
documents", not "user's files".

> There is even a `My Documents' folder for each user defined for the machine.
> (Another name for it can be Administrator's Documents, Drew's Documents, Eli's
> Documents. etc.)

Yes, that's the "virtual folder" part in the description on the above
URL.  But then you also have per-user "Application Data", "Temporary
Internet Files", "Favorites", and many more.  Being per user does not
mean it's up for grabs for any particular purpose.

> Why any program (e.g. bzr, apparently) would want to consider that folder as
> fair game for stuffing its internal stuff is beyond me.  How impolite.

Not at all.  It is customary, at least on Unix, to put logs, command
history, and other similar files in the user's home directory.

> Anyway, let's see what good ol' Wikipedia has to say...
> http://en.wikipedia.org/wiki/My_Documents
> 
>  My Documents is the name of a special folder on the computer's
>  hard drive that the system commonly uses to store a user's
>  documents, music, pictures, downloads, and other files.
> 
> Whaddya know?  And it says `My Documents' was introduced, "as a standard
> location for storing user-created files."

Don't believe everything Wikipedia says.

> Hm.  That all sounds just like what I think about it.  And about its subfolders,
> including `My Music',...  That "My" should tell us something, I would think.

Then why did that "My" part disappear in latest Windows versions?
There's no C:\Users\<username>\Documents etc., with "My Documents"
just a symlink.  See

  http://windows.microsoft.com/is-IS/windows-vista/What-happened-to-My-Documents

> `My Documents' is not the kind of place a civilized program would want to
> pollute with its own crap.

It's _your_ crap, because it's _you_ who runs that program.

> That is not the same as a place to stuff program-internal data.  We have
> `Program Files' and user-specific `Local Settings\Application Data' for that
> kind of thing.

As I wrote earlier, writing to "Program Files" is a bad idea, as it is
not writable in Vista and later.

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'files are written

[Dani Moncayo]

>> > Dani, where can I find the binary which fits this:
>>
>> (I've caught this by chance - I was not in the "to" or the "cc")
>
> ??? Of course you were in "To", take another look.

Brain fart, sorry.

-- 
Dani Moncayo

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

[Stefan Monnier]

>> > Accessing environment variables is another problematic place.  We are
>> > crashing, so the heap or the whole arena can be trashed.  Who can be
>> > sure the environment variables will not point to garbled places?
>> Just to put things in perspective: this backtrace "feature" was put in
>> to replace/supplement the previous assertion failure output (because
>> with asserts now being inside inlinable functions, the line&file info
>> we get is not the one we want any more).  So the environment is usually
>> still pretty sane, because assertions are usually caught fairly early.
> If the backtrace is created due to assertion violation, yes.  But it
> is also invoked for all the other fatal signals.

Yes, but the only case I care about is the assertion violation.
The other cases have never generated any useful output in the past
anyway and nobody complained abut that.


        Stefan

bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written

[Drew Adams]

> "The file system directory used to physically store a user's common
> repository of documents."  What do you make of that?  "User's
> documents", not "user's files".

A distinction without a meaning, in the present context.  Trouncing user stuff
is a no-no, whether that stuff is "documents" or files.

The distinction that matters here is user vs application.  The distinction
between documents and files is a red herring, unless I'm missing something.

> Yes, that's the "virtual folder" part in the description on the above
> URL.  But then you also have per-user "Application Data", "Temporary
> Internet Files", "Favorites", and many more.  Being per user does not
> mean it's up for grabs for any particular purpose.

I'm certainly not arguing that `My Documents' should be up for grabs by a
program for any particular purpose.  Far from it.  Well behaved programs store
user-specific internal data in places like `Application Data', NOT in `My
Documents'.  User-specific program data is not the same thing as user data.

You do not seem to want to recognize any difference between a user's photo of
his grandmother and a cache file used by a program to optimize access to that
photo.  (Hint: the user cares about Grandma; s?he does not care about the
cache.)

Why such a refusal to admit the obvious?  Is this about arguing and winning an
argument, or is it about progressing toward a solution?

You seem to want to emphasize the continuum and shades of gray, whose existence
no one would dispute, as an excuse not to recognize any distinction at all
between the ends of the spectrum.  (It's all connected; each electron is spread
out and penetrates the entire universe.  All is  o n e.) 

It is not all the same.  Red is not blue, even if there is a continuum of
wavelengths.  A program keeping to itself and its internal program thingies is
more likely to be well behaved than one that refuses to recognize any difference
between itself and the user.

> Not at all.  It is customary, at least on Unix, to put logs,
> command history, and other similar files in the user's home
> directory.

Yes, and it is just as customary, or at least likely, that Unix user Eunice will
put her documents/files in specific subdirectories under $HOME, and not just
sprinkle them at the top level of $HOME.  

(Not to mention the custom/handling (e.g. by listing programs, shell, and
various commands) of "hidden" dot files.  All is not equal, even on Unix.)

Argue this as you might for Unix, it is certainly the case on MS Windows, at
least, that it is customary for users NOT to mix their own documents/files in
with system data or application data.  And it is just as customary for
applications not to mix their data with user documents/files.

It's hard for me to believe this is even a point open to debate. 

> Don't believe everything Wikipedia says.

You don't seem to want to believe your own eyes.
The existence of green does not prove that red is blue.

> Then why did that "My" part disappear in latest Windows versions?
> There's no C:\Users\<username>\Documents etc., with "My Documents"
> just a symlink.
> http://windows.microsoft.com/is-IS/windows-vista/What-happened-to-My-Documents

Irrelevant.  (And you could have learned the same thing if you had read the
Wikipedia entry I cited, BTW.)

> > `My Documents' is not the kind of place a civilized program 
> > would want to pollute with its own crap.
> 
> It's _your_ crap, because it's _you_ who runs that program.

There you go again.  That, I guess, is your core argument:
it's all  o n e.

Sorry, I reject that argument entirely.  I won't repeat the reasons, unless you
really want me to.  Red is not blue.  User-specific app data is not the same
thing as user data.

Your program is not Eunice User, even if Eunice chooses to use your program.
Sure, if you ask her whether you can put your stuff in her folder, and she says
yes, then things are a bit different.  Then we're talking mutual consent, not
violation. ;-)

The question is what Emacs can do to minimize intrusion/annoyance.

Perhaps you'd prefer an opt-in EUA that Eunice must acknowledge in order to use
Emacs, and containing a provision that Emacs reserves the right to stick its
stuff anywhere at all?  Yes, in that case, by agreeing, Emacs's crap becomes
Eunice's crap.  I hope we can avoid that.

> > That is not the same as a place to stuff program-internal 
> > data.  We have `Program Files' and user-specific `Local 
> > Settings\Application Data' for that kind of thing.
> 
> As I wrote earlier, writing to "Program Files" is a bad idea,
> as it is not writable in Vista and later.

I said that programs store internal data in such places, and they do.  Whether
they also use `Program Files' to write new files to, once installed, is another
matter.  (And I don't hear you making the same claim wrt `Application Data',
BTW.)

Eli, please stop arguing peripheral minutiae.  Store program-internal data where
other programs do (on Windows).  That's all.  'Nuff said.

bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <dancol@dancol.org>, <12911@debbugs.gnu.org>
> Date: Tue, 20 Nov 2012 13:47:38 -0800
> 
> > "The file system directory used to physically store a user's common
> > repository of documents."  What do you make of that?  "User's
> > documents", not "user's files".
> 
> A distinction without a meaning, in the present context.  Trouncing user stuff
> is a no-no, whether that stuff is "documents" or files.

That's your interpretation.  It isn't written anywhere.

> The distinction that matters here is user vs application.

There's no distinction.

> You do not seem to want to recognize any difference between a user's photo of
> his grandmother and a cache file used by a program to optimize access to that
> photo.  (Hint: the user cares about Grandma; s?he does not care about the
> cache.)

Your hint is wrong.  I care about my caches dearly.

> It's hard for me to believe this is even a point open to debate. 

Well, it evidently is, and you fail to convince.  You are just
repeating yourself.

> > Don't believe everything Wikipedia says.
> 
> You don't seem to want to believe your own eyes.

I believe my experience.

> Store program-internal data where other programs do (on Windows).

Which is everywhere and nowhere.

bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

On 11/20/2012 7:47 PM, Eli Zaretskii wrote:
>> Store program-internal data where other programs do (on Windows).
> 
> Which is everywhere and nowhere.

All my other programs store program-generated files under AppData. None writes
indiscriminately to the current directory in the event of a crash.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

bug#12911: 24.3.50; let users decide where (& perhaps whether)`emacs_backtrace.txt' files are written

[Juanma Barranquero]

On Wed, Nov 21, 2012 at 5:03 AM, Daniel Colascione <dancol@dancol.org> wrote:

> All my other programs store program-generated files under AppData. None writes
> indiscriminately to the current directory in the event of a crash.

Do you have many Windows programs that do generate a backtrace file in
the event of failure? And do they all write to %APPDATA%?

If the answer to both questions is "yes", are these Cygwin programs?

    Juanma