GNU bug report logs -
#12911
24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written
Previous Next
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
View this message in rfc822 format
[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.