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

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

[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

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

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

> 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

[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

[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

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

[Drew Adams]

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

Why not add "and whose name is `Emacs'" while you're at it?

Seriously, this is not only about applications that generate a backtrace file.
It's about the etiquette that applications generally respect on Windows, in
order to respect the user and user data.

Why narrow it to applications that write backtrace files?  Is there something
particular about that case which should exclude it from respecting of the normal
etiquette?

Sure, if a program absolutely CANNOT respect the expected behavior because of
some hard constraint, then maybe that's a reason to make it an exception.  So
far, we haven't seen such a reason, AFAICT.  It might not be super simple for
Emacs to DTRT here, but that's not the same thing as saying that it CANNOT do
so.

And of course we have several decades of Emacs use without this new feature, in
which Emacs has not found it necessary to go beyond the pale.

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

[Juanma Barranquero]

On Wed, Nov 21, 2012 at 5:24 PM, Drew Adams <drew.adams@oracle.com> wrote:

> Why not add "and whose name is `Emacs'" while you're at it?

Because that would not make sense.

> Seriously, this is not only about applications that generate a backtrace file.

Yes, it is, because David said "[n]one writes indiscriminately to the
current directory in the event of a crash", and...

> It's about the etiquette that applications generally respect on Windows, in
> order to respect the user and user data.

...Emacs does NOT write files at random here and there. We're
specifically talking about a situation where Emacs is going down in
flames, and Eli choose a simple answer that does not require checking
remote accesses or environment variables. I would agree with you if
Emacs were prone to writing files in unexpected places, but a crash
backtrace is an exceptional circumstance.

Again: I understand that you're worried because you've said that
crashes are almost a daily occurrence for you. But I use the trunk
[Stefan: not really, I'm using emacs-24, I swear] and I cannot
remember the last time I had a crash other than assertion failures
after some sweeping "cleanup".

    Juanma

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

[Drew Adams]

> Again: I understand that you're worried because you've said that
> crashes are almost a daily occurrence for you. But I use the trunk
> [Stefan: not really, I'm using emacs-24, I swear] and I cannot
> remember the last time I had a crash other than assertion failures
> after some sweeping "cleanup".

NOT AT ALL.  Totally irrelevant.  This has nothing to do with me or my setup or
the frequency with which I experience crashes with Emacs 24.

I think you will find no mention by me in the bug report I filed for this, or in
any of my correspondence in the bug thread, of my daily crashes with Emacs 24 or
my concern for my own sake.  Red herring - you are apparently grasping at
straws.

My concern is that Emacs be respectful of users (not particularly me).  For my
personal use I could not care less where Emacs sticks backtrace files.

As to your argument that this is exceptional because Emacs is going down in
flames: I think Stefan has already spoken to that.  We have a choice in that
context regarding how polite Emacs should try to be.

I would say very polite - as polite as Emacs has always been.  You seem to be
saying that we cannot afford to be so polite when Rome is burning.

And I'm guessing you might also say that we cannot even give users the choice as
to how polite Emacs needs to be here, because when you're going down in flames
you cannot be checking user options (we've heard that wrt env vars).

We can agree to disagree about this.  To me, it is more important that Emacs
respect users than it is that Emacs save (and hopefully later send to Emacs Dev)
each and every backtrace.  We've gotten by OK for decades now without such an
annoyance.  And we can apparently (IIUC) find ways to get at least some such
backtrace feedback (i.e, sometimes) without the annoyance.

IIUC, Stefan and Eli have both said that it is only in some cases that Emacs
would not be able to save the backtrace data, if we required Emacs to respect
users and stay out of their folders.  (However, I'm no expert on the
implementation question, and it's quite possible I have misunderstood.)

I say that if that is the case then Emacs Dev should pay the (small) price and
forego those particular backtraces.  Not a big deal, IMHO.  Not as big a deal
as, in effect, telling users that Emacs does not care about their data.

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

[Juanma Barranquero]

On Wed, Nov 21, 2012 at 6:40 PM, Drew Adams <drew.adams@oracle.com> wrote:

> Red herring - you are apparently grasping at straws.

Thanks, it is always great to be read in such a favorable light.

> You seem to be
> saying that we cannot afford to be so polite when Rome is burning.

No, I'm saying that this is much ado about almost nothing.

    Juanma

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

[Drew Adams]

> > Red herring - you are apparently grasping at straws.
> 
> Thanks, it is always great to be read in such a favorable light.

Sorry if I hurt your feelings somehow.  But what would you call it, bringing my
personal use of Emacs into the discussion as if it were the motivation behind my
filing the bug report and arguing for a fix?  It is not, at all.

To me, that red herring (which it is) was an ad hominem turn in the road - let's
look at Drew, not Drew's message.  Irrelevant to the discussion.  And far
removed from any argument I have made here.

Don't get me wrong.  I do not say that it was an ad hominem attack in any way;
it was not an attack.  It was just an irrelevant distraction.

But let me know if I'm missing something in your argument.  And again, sorry if
something I said caused hard feelings - none were intended.

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

[Juanma Barranquero]

On Wed, Nov 21, 2012 at 7:01 PM, Drew Adams <drew.adams@oracle.com> wrote:

> To me, that red herring (which it is) was an ad hominem turn in the road - let's
> look at Drew, not Drew's message.

Mine wasn't an ad hominem, because I haven't said that your arguments
are wrong because they are yours. I think they are wrong because they
put emphasis in something that happens very rarely, and suggest adding
complexity to something that is very simple. AND I've *pointed out*
that the relative importance of that problem is greater for you than
for me, because you are more likely to get affected by it. That could
affect your judgment (it would likely affect mine; I get angry when
people who doesn't ever use line-by-line scrolling start suggesting
changes to scroll-conservatively and Emacs recentering, or when
non-Windows users suggest that some changes won't affect the Windows
port, or that if they do affect it, is all Microsoft's fault).

> Don't get me wrong.  I do not say that it was an ad hominem attack in any way;
> it was not an attack.  It was just an irrelevant distraction.

I find an irrelevant distraction that you're discussing "[...] the
etiquette that applications generally respect on Windows, in order to
respect the user and user data" when the thread is specifically about
*one* file, in *one* specific situation, which is a crash backtrace.

    Juanma

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

[Drew Adams]

> I find an irrelevant distraction that you're discussing "[...] the
> etiquette that applications generally respect on Windows, in order to
> respect the user and user data" when the thread is specifically about
> *one* file, in *one* specific situation, which is a crash backtrace.

It's in fact as far as you can get from irrelevant.  That's precisely what this
bug report is about: the placement by Emacs of that "*one* file, in *one*
specific situation, which is a crash backtrace", into a user folder.

So perhaps this bug report is altogether irrelevant and a distraction to you.
Fair enough.

What can I say, in that case?  We're back to agreeing to disagree.  I think that
that *one* case of disrespecting users should be removed; you think that that
regression should stay, because it is an improvement.

We apparently do not disagree about the other cases for this new feature: the
cases where user folders are not written into.  We both are in favor of the new
feature in those cases.

We apparently disagree only about that *one* corner case, where Emacs apparently
cannot do otherwise than to write its backtrace into a user folder.  That's the
case this bug report is about.

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

[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

[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

[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

[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

[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

[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

[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

selected-frame and selected-window

[Stefan Monnier]

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

I'm not sure is that assertion is actually right.

99% of the time the (frame-selected-window) is the same as the
(selected-window), but there are some exceptions.  So far I found two:

- one in the redisplay, where we change selected-frame (without changing
  selected-window) just to get the frame-local variables.  As soon as we
  drop frame-local variables, this one will disappear (e.g. it's gone in
  my local branch).
- one in the mode-line computation.  This one is nasty because it is
  visible to lisp: while running an (:eval <form>) element, we change
  selected-window (without changing frame-selected-window) to the window
  being redisplayed.  So in <form>, it is not always true that
  (eq (selected-window) (frame-selected-window)).  To some extent this
  could be a feature (lets you return different data for the mode-line
  depending on whether it's selected or not), but I'd rather get this
  information differently since it is so easy to assume that
  (eq (selected-window) (frame-selected-window)) without being aware of it.

There might be more cases: I added a whole bunch of `eassert's where the
assertion is refined to try and take the above discrepancies into
account, and those get caught occasionally.  I haven't managed to track
down their cause yet.  It might just be a bug in the assertions.


        Stefan

Re: selected-frame and selected-window

[Stefan Monnier]

> 99% of the time the (frame-selected-window) is the same as the
> (selected-window), but there are some exceptions.  So far I found two:

I just found and corrected (on trunk) a third case (in update_tool_bar).


        Stefan

Re: selected-frame and selected-window

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Tue, 20 Nov 2012 15:37:05 -0500
> 
> > 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.
> 
> I'm not sure is that assertion is actually right.

Well, "bzr annotate" says you added it ;-)

Should we just go ahead and remove it?  Inaccurate assertions are a
maintenance headache, to say nothing of user aggravation.

Re: selected-frame and selected-window

[Stefan Monnier]

>> > 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.
>> I'm not sure is that assertion is actually right.
> Well, "bzr annotate" says you added it ;-)
> Should we just go ahead and remove it?  Inaccurate assertions are a
> maintenance headache, to say nothing of user aggravation.

The rest of my message mentioned reasons why the equality is
sometimes broken.  Now, I tend to consider that those cases should be
considered bugs, because IIRC there are cases where we do rely on this
equality.  More specifically, I added such easserts in an effort to
track the origin of an error.

But to fix these bugs we need to figure out how to handle the "mode-line
:eval" case.


        Stefan

Re: selected-frame and selected-window

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sat, 08 Dec 2012 18:51:40 -0500
> 
> >> > 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.
> >> I'm not sure is that assertion is actually right.
> > Well, "bzr annotate" says you added it ;-)
> > Should we just go ahead and remove it?  Inaccurate assertions are a
> > maintenance headache, to say nothing of user aggravation.
> 
> The rest of my message mentioned reasons why the equality is
> sometimes broken.

Yes, I know.  But a broken assertion is a candidate for removal, IMO.

> Now, I tend to consider that those cases should be considered bugs,
> because IIRC there are cases where we do rely on this equality.

If you or someone else can describe those cases, we could use that
knowledge to modify the assertion or fix the bugs which violate it.

> More specifically, I added such easserts in an effort to track the
> origin of an error.

We are evidently unable to do that in a long time.  All we do is cause
user aggravation and add to maintenance load.

> But to fix these bugs we need to figure out how to handle the "mode-line
> :eval" case.

Do you have any practical suggestions for that?

Re: selected-frame and selected-window

[Stefan Monnier]

>> The rest of my message mentioned reasons why the equality is
>> sometimes broken.
> Yes, I know.  But a broken assertion is a candidate for removal, IMO.

Agreed.

>> Now, I tend to consider that those cases should be considered bugs,
>> because IIRC there are cases where we do rely on this equality.
> If you or someone else can describe those cases, we could use that
> knowledge to modify the assertion or fix the bugs which violate it.

I did describe them.  I actually just installed a tentative fix for
those problems.


        Stefan

Re: selected-frame and selected-window

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 14 Dec 2012 10:53:32 -0500
> 
> I actually just installed a tentative fix for those problems.

Great, thanks.

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.