bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_ba


From: Daniel Colascione
Subject: 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
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]