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

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Fri, 16 Nov 2012 20:50:01 UTC

Severity: normal

Tags: wontfix

Found in version 24.3.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12911 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether)
	`emacs_backtrace.txt'	files are written
Date: Tue, 20 Nov 2012 09:36:36 -0800
[Message part 1 (text/plain, inline)]
On 11/20/12 9:03 AM, Eli Zaretskii wrote:
>> Date: Mon, 19 Nov 2012 21:02:22 -0800
>> From: Daniel Colascione <dancol <at> dancol.org>
>> CC: Eli Zaretskii <eliz <at> gnu.org>, 12911 <at> 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.


[signature.asc (application/pgp-signature, attachment)]

This bug report was last modified 12 years and 236 days ago.

Previous Next


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