bug#19868: #19868 25.0.50; Compilation eats buffers

[Eli Zaretskii <eliz@gnu.org>]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Mon, 15 Aug 2016 18:19:05 -0400
> Cc: 19868@debbugs.gnu.org, Richard Copley <rcopley@gmail.com>
> 
> On Sat, Aug 13, 2016 at 2:44 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Noam Postavsky <npostavs@users.sourceforge.net>
> >> Date: Fri, 12 Aug 2016 16:47:07 -0400
> >> Cc: Richard Copley <rcopley@gmail.com>
> >>
> >> I reproduced this (the hanging, not the buffer eating) on Windows 10,
> >> Emacs 25.1, MinGW64.  Stepping with gdb I found the the hang occurs in
> >> sys_close where it calls _close (fd).  This is being called from
> >> deactivate_process:
> >>
> >>   for (i = 0; i < PROCESS_OPEN_FDS; i++)
> >>     close_process_fd (&p->open_fd[i]); // <-- when i == 2
> >
> > Does it hang in the _close call itself, or somewhere else?
> 
> It's in the _close call itself.

Hm... not so good.

> > And what is the value of fd?
> >
> > Can you instrument the relevant code with printf's and see this
> > happening without stepping through the code with GDB?  Doing the
> > latter might change the timing of the calls, so we might be trying to
> > use file descriptors when the process (cmdproxy) is already dead, and
> > so the other end of the pipe no longer exists.
> 
> I put fprintf+fflush before close_process_fd and around _close:
> 
> close_process_fd(-1[i = 0])
> close_process_fd(4[i = 1])
> going to _close(4)...done _close(4)
> close_process_fd(5[i = 2])
> going to _close(5)... // here Emacs hangs until I kill bug.exe

Can you tell what descriptor 5 is open on?  Is it for input, for
output, for something else?

Also, is "until I kill bug.exe" accurate?  That program just waits for
5 seconds, so after that it should exit by itself.  Are you saying it
doesn't unless killed by external means?

Thanks.