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: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Powell <stephen_powell <at> optusnet.com.au>
Cc: 13086 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, 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 21:36:15 +0200
> Date: Thu, 06 Dec 2012 19:10:54 +0000
> From: Stephen Powell <stephen_powell <at> optusnet.com.au>
> CC: eggert <at> cs.ucla.edu, stephen_powell <at> optusnet.com.au, 13086 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I also found some potential problem in w32proc.c, and fixed that in
> > revision 111132 on the trunk.  Stephen, please try the latest code and
> > see if the problem persists.
> 
> OK, I tried that revision with the same problem.
> 
> I don't really know what I'm doing, but one odd thing I noticed while
> playing around with Paul's suggestion to set a breakpoint on
> delete_process:
> 
> 1. Set a breakpoint on process.c:808. Print p.pid and do a xbacktrace.
> 2. Run gnus.
> 3. Gnus uses imap.el to get mail from my host.
> 4. Imap.el calls delete-process from imap-close
> 
> $1 = 1356
> "delete-process" (0x88bf48)
> "imap-close" (0x88c248)
> "mail-source-fetch-imap" (0x88c584)
> 
> 5. Imap.el calls delete-process to delete the same pid from
> imap-sentinel
> 
> $2 = 1356
> "delete-process" (0x88b928)
> "imap-sentinel" (0x88bc24)
> "delete-process" (0x88bf48)
> "imap-close" (0x88c248)
> "mail-source-fetch-imap" (0x88c584)
> 
> 6. Let gnus sit for about a minute.  The error is signalled with the
> same pid
> 
> Breakpoint 1, terminate_due_to_signal (sig=22,
> backtrace_limit=2147483647) at emacs.c:314
> 314	  signal (sig, SIG_DFL);
> (gdb) up 2
> #2  0x0114a8db in get_child_status (child=1356, status=0x0, options=1,
> interruptible=false) at sysdep.c:294
> 294	      eassert (errno == EINTR);

What is the value of errno in frame #2?  Also, can you tell through
which line does waitpid exit in this case?




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.