From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13086: 24.2.50; Emacs seems to hang at w32proc.c:1126 Date: Thu, 06 Dec 2012 05:51:30 +0200 Message-ID: <83pq2nq1ml.fsf@gnu.org> References: <50BFA054.1060503@optusnet.com.au> <83r4n4p4wt.fsf@gnu.org> <50BFFD14.5010102@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1354765918 11781 80.91.229.3 (6 Dec 2012 03:51:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2012 03:51:58 +0000 (UTC) Cc: 13086@debbugs.gnu.org, stephen_powell@optusnet.com.au To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 06 04:52:10 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TgSVL-00052x-A7 for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Dec 2012 04:52:07 +0100 Original-Received: from localhost ([::1]:52973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgSV9-0003Oh-FT for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Dec 2012 22:51:55 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgSV7-0003Oc-AI for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2012 22:51:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TgSV6-0005Ku-0I for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2012 22:51:53 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgSV5-0005Ko-So for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2012 22:51:51 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TgSVG-0007Cw-Ae for bug-gnu-emacs@gnu.org; Wed, 05 Dec 2012 22:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Dec 2012 03:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13086 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13086-submit@debbugs.gnu.org id=B13086.135476590327667 (code B ref 13086); Thu, 06 Dec 2012 03:52:02 +0000 Original-Received: (at 13086) by debbugs.gnu.org; 6 Dec 2012 03:51:43 +0000 Original-Received: from localhost ([127.0.0.1]:55624 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgSUw-0007CB-VO for submit@debbugs.gnu.org; Wed, 05 Dec 2012 22:51:43 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:46731) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgSUu-0007C2-7U for 13086@debbugs.gnu.org; Wed, 05 Dec 2012 22:51:41 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MEL00C00BYY1S00@a-mtaout22.012.net.il> for 13086@debbugs.gnu.org; Thu, 06 Dec 2012 05:51:27 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEL00B44C1R90F0@a-mtaout22.012.net.il>; Thu, 06 Dec 2012 05:51:27 +0200 (IST) In-reply-to: <50BFFD14.5010102@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:68007 Archived-At: > Date: Wed, 05 Dec 2012 18:04:04 -0800 > From: Paul Eggert > CC: Stephen Powell , > 13086@debbugs.gnu.org > > On 12/05/2012 01:25 PM, Eli Zaretskii wrote: > > Paul, can you tell why it loops if waitpid is called with WNOHANG and > > returns -1? Won't that cause a busy-wait loop that pegs the CPU? > > If waitpid is called with WNOHANG and returns -1, then > errno must equal EINTR. (There's an assertion for this.) Is that necessarily the case? I don't see that in the Posix specification, which says: RETURN VALUE If wait() or waitpid() returns because the status of a child process is available, these functions will return a value equal to the process ID of the child process for which status is reported. If wait() or waitpid() returns due to the delivery of a signal to the calling process, -1 will be returned and errno will be set to [EINTR]. If waitpid() was invoked with WNOHANG set in options, it has at least one child process specified by pid for which status is not available, and status is not available for any process specified by pid, 0 will be returned. Otherwise, (pid_t)-1 will be returned, and errno will be set to indicate the error. ERRORS The waitpid() function will fail if: [ECHILD] The process or process group specified by pid does not exist or is not a child of the calling process. [EINTR] The function was interrupted by a signal. The value of the location pointed to by stat_loc is undefined. [EINVAL] The options argument is not valid. My reading of this, and specifically of the last sentence under "RETURN VALUE", is that errno could also be ECHILD. Am I missing something? > Presumably Emacs is confused, and is waiting for a process > that it already waited for. That's a bug and we should fix it. Perhaps so, but inflooping in that case is hardly a Good Thing, is it? And neither is aborting when asserts are enabled. Perhaps signaling an error would be better. > I can't tell from the info so far whether the bug is in > the w32 implementation of waitpid, or in Emacs proper. I don't know yet either, but I thought I need to understand the logic of that loop before I make up my mind, because the w32 waitpid implementation should behave according to the expectations of its callers. > Was this emacs compiled with error-checking turned on > (./configure --enable-checking, or whatever equivalent is > use in the Microsoft Windows world)? > If so, I'm puzzled as to why the 'eassert (errno == EINTR)' > didn't fire. If not, can you reproduce the bug with > error-checking enabled? Stephen, can you do that, please?