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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 13086 <at> debbugs.gnu.org, stephen_powell <at> optusnet.com.au
Subject: Re: bug#13086: 24.2.50; Emacs seems to hang at w32proc.c:1126
Date: Thu, 06 Dec 2012 22:25:29 +0200

> Date: Thu, 06 Dec 2012 12:18:36 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: stephen_powell <at> optusnet.com.au, 13086 <at> debbugs.gnu.org
> 
> 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.

How can that happen, if PID is not our child process?

And even if it does happen, the hypothetical problem you envision
hardly justify losing an Emacs session.

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

It is much easier to remove the offending process object from the list
of those we expect to be dead.

Previous Next

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