bug#13086: 24.2.50; Emacs seems to hang at w32proc.c:1126

[Eli Zaretskii]

> Date: Wed, 05 Dec 2012 18:04:04 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Stephen Powell <stephen_powell@optusnet.com.au>, 
>  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?