GNU bug report logs - #13086
24.2.50; Emacs seems to hang at w32proc.c:1126

Previous Next

Package: emacs;

Reported by: Stephen Powell <stephen_powell <at> optusnet.com.au>

Date: Wed, 5 Dec 2012 07:23:01 UTC

Severity: normal

Merged with 13157

Found in versions 24.2.50, 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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13086 <at> debbugs.gnu.org, stephen_powell <at> optusnet.com.au
Subject: bug#13086: 24.2.50; Emacs seems to hang at w32proc.c:1126
Date: Thu, 06 Dec 2012 12:18:36 -0800
On 12/06/12 10:28, Eli Zaretskii wrote:
> Yes, but we usually do that only if Emacs cannot possibly recover from
> that internal error.  If Emacs _can_ continue, then we only abort via
> eassert, so that a production version won't crash.

Well, it depends on what "recovery" means.  In this case, if
Emacs ignores the error and continues, it will have a confused
data structure that can cause it to kill unrelated innocent-victim
processes seemingly at random.  Such a bug would be rare and hard to
track down -- I would not be surprised if users have run across
this bug in the wild but have not known that Emacs was the culprit
and have assumed it was a Heisenbug in the innocent-victim program.

One possibility is for Emacs to fall back into recovery mode, such
as what it does now when it runs out of memory.  That is, Emacs
would tell you that it has had an internal error and that you should
save your work and exit as soon as you can.  This would lessen
the likelihood of the confused Emacs causing further damage.




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

Previous Next


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