bug#19868: #19868 25.0.50; Compilation eats buffers

[Noam Postavsky <npostavs@users.sourceforge.net>]

On Tue, Aug 16, 2016 at 10:18 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> 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?

I found this enum which indicates that i=2 would be READ_FROM_SUBPROCESS.
/* Indexes of file descriptors in open_fds.  */
enum
  {
    /* The pipe from Emacs to its subprocess.  */
    SUBPROCESS_STDIN,
    WRITE_TO_SUBPROCESS,

    /* The main pipe from the subprocess to Emacs.  */
    READ_FROM_SUBPROCESS,
    SUBPROCESS_STDOUT,

I confirmed with printfs that open_fd[2] is set to 5 by the
emacs_pipe() calls in create_process (I also double checked with gdb
that nobody else sets it in between).

I printed all open_fd values from deactivate_process, just before the
closing loop, I got

deactivate_process()open_fd[0] = -1, open_fd[1] = 4, open_fd[2] = 5,
open_fd[3] = -1, open_fd[4] = -1, open_fd[5] = -1,

So, only WRITE_TO_SUBPROCESS and READ_FROM_SUBPROCESS are open. When
compiling bug.c without -mwindows, all open_fd values are -1 at that
spot.

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

Ah, sorry, I upped the waiting time to 5 minutes, because 5 seconds
seemed a bit short for debugging. So I should have said "until bug.exe
terminates" (either by itself, or because I told it to).

Another observation: if I close Emacs while it's running bug.exe,
Emacs closes successfully, but leaves bug.exe running (even though I
answer yes at the prompt to kill it).