GNU logs - #19868, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#19868: 25.0.50; Compilation eats buffers
Resent-From: Richard Copley <rcopley@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 14 Feb 2015 19:31:02 +0000
Resent-Message-ID: <handler.19868.B.142394226128548 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 19868 <at> debbugs.gnu.org
MIME-Version: 1.0
Date: Sat, 14 Feb 2015 19:30:45 +0000
Message-ID: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
From: Richard Copley <rcopley@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On Windows, with MinGW gcc.exe installed and on the path, save a file
"c:\temp\bug.c" containing these two lines:

#include <windows.h>
int main () { Sleep (5000); }

Compile with "M-x compile RET", supplying this compile-command:
gcc -mwindows -o bug.exe bug.c && bug.exe

Within 5 seconds, execute "M-x compile" again and answer "yes" to kill
the existing process. The process doesn't respond to the signal,
and Emacs hangs inside the call to `delete-process' in
`compilation-start'.

When the process does eventually die and the `delete-process' call
returns, the current buffer has changed from *compilation* to the buffer
from which the compilation was launched (which will often be a source
code buffer).

`compilation-start' then proceeds to erase the buffer and discard its
undo history. This is potentially very bad news for the user's source
code.

I'm not sure where the buffer gets changed (presumably in a sentinel,
but `compilation-sentinel' looks OK to me). Wrapping the
`delete-process' call inside a `save-excursion' fixes (or hides?) the
problem.

In GNU Emacs 25.0.50.1 (x86_64-w64-mingw32)
 of 2015-02-09 on MACHINE
Repository revision: 21d1f8b85eec8fc1f87bb30398e449f6b20b6ecc
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
 `configure --prefix /c/emacs/emacs-20150209-192633
 --disable-dependency-tracking
 --enable-locallisppath=%emacs_dir%/../site-lisp --with-wide-int
 --build=x86_64-w64-mingw32 'CPPFLAGS=-I G:/usr/include -I
 C:/GnuWin32/include' 'LDFLAGS=-L G:/usr/lib -L C:/GnuWin32/lib''

Configured features:
XPM JPEG TIFF GIF PNG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Richard Copley <rcopley@HIDDEN>
Subject: bug#19868: Acknowledgement (25.0.50; Compilation eats buffers)
Message-ID: <handler.19868.B.142394226128548.ack <at> debbugs.gnu.org>
References: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
X-Gnu-PR-Message: ack 19868
X-Gnu-PR-Package: emacs
Reply-To: 19868 <at> debbugs.gnu.org
Date: Sat, 14 Feb 2015 19:31:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 19868 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
19868: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D19868
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#19868: 25.0.50; Compilation eats buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 15 Feb 2015 17:54:01 +0000
Resent-Message-ID: <handler.19868.B19868.142402280222069 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Richard Copley <rcopley@HIDDEN>
Cc: 19868 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Date: Sun, 15 Feb 2015 19:53:16 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
Message-id: <83k2zjukmr.fsf@HIDDEN>
References: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Date: Sat, 14 Feb 2015 19:30:45 +0000
> From: Richard Copley <rcopley@HIDDEN>
> 
> On Windows, with MinGW gcc.exe installed and on the path, save a file
> "c:\temp\bug.c" containing these two lines:
> 
> #include <windows.h>
> int main () { Sleep (5000); }
> 
> Compile with "M-x compile RET", supplying this compile-command:
> gcc -mwindows -o bug.exe bug.c && bug.exe
> 
> Within 5 seconds, execute "M-x compile" again and answer "yes" to kill
> the existing process. The process doesn't respond to the signal,

There are no signals on Windows.  Emacs simulates SIGINT and SIGKILL
by other means, see sys_kill.

> and Emacs hangs inside the call to `delete-process' in
> `compilation-start'.
> 
> When the process does eventually die and the `delete-process' call
> returns, the current buffer has changed from *compilation* to the buffer
> from which the compilation was launched (which will often be a source
> code buffer).
> 
> `compilation-start' then proceeds to erase the buffer and discard its
> undo history. This is potentially very bad news for the user's source
> code.

I cannot reproduce this: for me, Emacs doesn't hang at all.  As soon
as I answer YES to the kill process question, I see in Process
Explorer that cmdproxy, cmd.exe, and the program that sleeps are all
terminated, and the new compilation begins.  Like I'd expect.

If I instrument the sys_kill function, I see that we first send a
simulated Ctrl-C keystroke to the process, and a second afterwards
terminate it forcefully, which is consistent with the calls to
interrupt-process and delete-process in compilation-start.

I tried this on Windows 7 and XP, and both show the same correct
behavior.

It could be that what you see is specific to Windows 8, or to 64-bit
programs, or to how MinGW64 sets up the process in its startup code (I
used MinGW32).

You say above that Emacs hangs inside the delete-process call -- can
you show a backtrace in that state, preferably from an unoptimized
build?  I'd like to see where exactly it hangs.

Also, is the -mwindows compiler switch a factor here, i.e. does the
problem happen with a console application that sleeps?  (I'm not sure
it should matter, because the process that we are killing is cmdproxy,
not the program you compiled.)

In addition, can you look at the relevant processes in Process
Explorer and seed if any of them are killed when you answer YES?

> I'm not sure where the buffer gets changed (presumably in a sentinel,
> but `compilation-sentinel' looks OK to me).

Run all this under GDB, put a breakpoint on a low-level function that
switches buffers (e.g., in set_buffer_internal), and you will see in
the backtrace which Lisp function triggers that.  It is advisable to
manually load compile.el in advance, so that xbacktrace shows more
details.

> In GNU Emacs 25.0.50.1 (x86_64-w64-mingw32)
>  of 2015-02-09 on MACHINE
> Repository revision: 21d1f8b85eec8fc1f87bb30398e449f6b20b6ecc
> Windowing system distributor `Microsoft Corp.', version 6.3.9600
> Configured using:
>  `configure --prefix /c/emacs/emacs-20150209-192633
>  --disable-dependency-tracking
>  --enable-locallisppath=%emacs_dir%/../site-lisp --with-wide-int
>  --build=x86_64-w64-mingw32 'CPPFLAGS=-I G:/usr/include -I
>  C:/GnuWin32/include' 'LDFLAGS=-L G:/usr/lib -L C:/GnuWin32/lib''

Any idea why you are building --with-wide-int?  It's supposed to be a
no-op in a 64-bit build.  (This is not related to the bug.)

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#19868: 25.0.50; Compilation eats buffers
Resent-From: Richard Copley <rcopley@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 17 Feb 2015 00:26:01 +0000
Resent-Message-ID: <handler.19868.B19868.142413275029122 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 19868 <at> debbugs.gnu.org
MIME-Version: 1.0
In-Reply-To: <83k2zjukmr.fsf@HIDDEN>
References: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
 <83k2zjukmr.fsf@HIDDEN>
Date: Tue, 17 Feb 2015 00:25:41 +0000
Message-ID: <CAPM58oiOa8_wBO=R8q+yESmjX3bUgEam3ujA59D35iBv4xaDFg@HIDDEN>
From: Richard Copley <rcopley@HIDDEN>
Content-Type: multipart/mixed; boundary=001a1132e9ca271079050f3dbe37
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--001a1132e9ca271079050f3dbe37
Content-Type: text/plain; charset=UTF-8

On 15 February 2015 at 17:53, Eli Zaretskii <eliz@HIDDEN> wrote:
>>
>> On Windows, with MinGW gcc.exe installed and on the path, save a file
>> "c:\temp\bug.c" containing these two lines:
>>
>> #include <windows.h>
>> int main () { Sleep (5000); }
>>
>> Compile with "M-x compile RET", supplying this compile-command:
>> gcc -mwindows -o bug.exe bug.c && bug.exe
>>
>> Within 5 seconds, execute "M-x compile" again and answer "yes" to kill
>> the existing process. The process doesn't respond to the signal,
>
> There are no signals on Windows.  Emacs simulates SIGINT and SIGKILL
> by other means, see sys_kill.
>
>> and Emacs hangs inside the call to `delete-process' in
>> `compilation-start'.
>>
>> When the process does eventually die and the `delete-process' call
>> returns, the current buffer has changed from *compilation* to the buffer
>> from which the compilation was launched (which will often be a source
>> code buffer).
>>
>> `compilation-start' then proceeds to erase the buffer and discard its
>> undo history. This is potentially very bad news for the user's source
>> code.
>
> I cannot reproduce this: for me, Emacs doesn't hang at all.  As soon
> as I answer YES to the kill process question, I see in Process
> Explorer that cmdproxy, cmd.exe, and the program that sleeps are all
> terminated, and the new compilation begins.  Like I'd expect.
>
> If I instrument the sys_kill function, I see that we first send a
> simulated Ctrl-C keystroke to the process, and a second afterwards
> terminate it forcefully, which is consistent with the calls to
> interrupt-process and delete-process in compilation-start.
>
> I tried this on Windows 7 and XP, and both show the same correct
> behavior.
>
> It could be that what you see is specific to Windows 8, or to 64-bit
> programs, or to how MinGW64 sets up the process in its startup code (I
> used MinGW32).

I see my problem no matter what compiler I use to build "bug.exe"
(old-fashioned MinGW32, and both the 32- and 64-bit MinGW-W64
GCC 4.9.2 toolchains). I'll try on Windows 7, and if I get time,
with 32-bit Emacs.

when building "bug.exe" with good old MinGW and with
both the 32- and 64-bit toolchains from MinGW-W64. I haven't tried it
with a 32-bit Emacs. I will try that, and on Windows 7, when I have time.

> You say above that Emacs hangs inside the delete-process call -- can
> you show a backtrace in that state, preferably from an unoptimized
> build?  I'd like to see where exactly it hangs.

I tried to work out how to control the optimization level when building
Emacs but I'm stumped. How do you do that? (If there are configure
flags, can they be mentioned in "configure --help"?)

FWIW, attached is the result of "thread apply all bt full" after typing
Ctrl-C in GDB while debugging an optimized Emacs that was hanging.
Looks like I'm doing something horribly wrong. Sorry about that.

> Also, is the -mwindows compiler switch a factor here, i.e. does the
> problem happen with a console application that sleeps?

Yes, -mwindows is needed. Console applications die as expected.

> (I'm not sure it should matter, because the process that we are
> killing is cmdproxy, not the program you compiled.)

Then I don't understand why a GUI program would ever die in response
to that. (Would runemacs.exe?) Really I didn't expect it to; that's
not the bug I was reporting (though I'm happy to help fix it if it is
a bug).

> In addition, can you look at the relevant processes in Process
> Explorer and seed if any of them are killed when you answer YES?

"cmdproxy.exe" and its descendants "cmd.exe" and "conhost.exe"
are killed, leaving just the orphaned "bug.exe".

>> I'm not sure where the buffer gets changed (presumably in a sentinel,
>> but `compilation-sentinel' looks OK to me).
>
> Run all this under GDB, put a breakpoint on a low-level function that
> switches buffers (e.g., in set_buffer_internal), and you will see in
> the backtrace which Lisp function triggers that.  It is advisable to
> manually load compile.el in advance, so that xbacktrace shows more
> details.

I'm sorry to say that, mysteriously, I can no longer reproduce the
effect where the current buffer changes during the `delete-process'
call and causes work to be lost. I can't see what I'm doing differently.
I might have to get back to you another time.

>> In GNU Emacs 25.0.50.1 (x86_64-w64-mingw32)
>>  of 2015-02-09 on MACHINE
>> Repository revision: 21d1f8b85eec8fc1f87bb30398e449f6b20b6ecc
>> Windowing system distributor `Microsoft Corp.', version 6.3.9600
>> Configured using:
>>  `configure --prefix /c/emacs/emacs-20150209-192633
>>  --disable-dependency-tracking
>>  --enable-locallisppath=%emacs_dir%/../site-lisp --with-wide-int
>>  --build=x86_64-w64-mingw32 'CPPFLAGS=-I G:/usr/include -I
>>  C:/GnuWin32/include' 'LDFLAGS=-L G:/usr/lib -L C:/GnuWin32/lib''
>
> Any idea why you are building --with-wide-int?  It's supposed to be a
> no-op in a 64-bit build.  (This is not related to the bug.)

I'll remove it, thanks.

--001a1132e9ca271079050f3dbe37
Content-Type: text/plain; charset=US-ASCII; name="bt.txt"
Content-Disposition: attachment; filename="bt.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i68ho4rl0

UHJvZ3JhbSByZWNlaXZlZCBzaWduYWwgU0lHSU5ULCBJbnRlcnJ1cHQuDQpbU3dpdGNoaW5nIHRv
IFRocmVhZCA4NTY4LjB4MTUxOF0NCjB4MDAwMDdmZjljNWNjMzIzMyBpbiBSZWdMb2FkTVVJU3Ry
aW5nQSAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXHN5c3RlbTMyXEtlcm5lbEJhc2UuZGxsDQooZ2Ri
KSB0aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGwNCg0KVGhyZWFkIDcgKFRocmVhZCA4NTY4LjB4MTUx
OCk6DQojMCAgMHgwMDAwN2ZmOWM1Y2MzMjMzIGluIFJlZ0xvYWRNVUlTdHJpbmdBICgpDQogICBm
cm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJcS2VybmVsQmFzZS5kbGwNCk5vIHN5bWJvbCB0YWJsZSBp
bmZvIGF2YWlsYWJsZS4NCkJhY2t0cmFjZSBzdG9wcGVkOiBwcmV2aW91cyBmcmFtZSBpZGVudGlj
YWwgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8pDQoNClRocmVhZCA2IChUaHJlYWQgODU2
OC4weDQ1MCk6DQojMCAgMHgwMDAwN2ZmOWM4YWEyOGNhIGluIG50ZGxsIVp3V2FpdEZvcldvcmtW
aWFXb3JrZXJGYWN0b3J5ICgpDQogICBmcm9tIEM6XFdJTkRPV1NcU1lTVEVNMzJcbnRkbGwuZGxs
DQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojMSAgMHgwMDAwN2ZmOWM4YTQ0ZDI2
IGluIG50ZGxsIVJ0bEZyZWVVbmljb2RlU3RyaW5nICgpDQogICBmcm9tIEM6XFdJTkRPV1NcU1lT
VEVNMzJcbnRkbGwuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojMiAgMHgw
MDAwN2ZmOWM4ODIxM2QyIGluIEtFUk5FTDMyIUJhc2VUaHJlYWRJbml0VGh1bmsgKCkNCiAgIGZy
b20gQzpcV0lORE9XU1xzeXN0ZW0zMlxrZXJuZWwzMi5kbGwNCk5vIHN5bWJvbCB0YWJsZSBpbmZv
IGF2YWlsYWJsZS4NCiMzICAweDAwMDA3ZmY5YzhhN2ViNjQgaW4gbnRkbGwhUnRsVXNlclRocmVh
ZFN0YXJ0ICgpDQogICBmcm9tIEM6XFdJTkRPV1NcU1lTVEVNMzJcbnRkbGwuZGxsDQpObyBzeW1i
b2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojNCAgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgp
DQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQpCYWNrdHJhY2Ugc3RvcHBlZDogcHJl
dmlvdXMgZnJhbWUgaW5uZXIgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8pDQoNClRocmVh
ZCA1IChUaHJlYWQgODU2OC4weDE4MTQpOg0KIzAgIDB4MDAwMDdmZjljOGFhMjhjYSBpbiBudGRs
bCFad1dhaXRGb3JXb3JrVmlhV29ya2VyRmFjdG9yeSAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXFNZ
U1RFTTMyXG50ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzEgIDB4
MDAwMDdmZjljOGE0NGQyNiBpbiBudGRsbCFSdGxGcmVlVW5pY29kZVN0cmluZyAoKQ0KICAgZnJv
bSBDOlxXSU5ET1dTXFNZU1RFTTMyXG50ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh
aWxhYmxlLg0KIzIgIDB4MDAwMDdmZjljODgyMTNkMiBpbiBLRVJORUwzMiFCYXNlVGhyZWFkSW5p
dFRodW5rICgpDQogICBmcm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJca2VybmVsMzIuZGxsDQpObyBz
eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojMyAgMHgwMDAwN2ZmOWM4YTdlYjY0IGluIG50
ZGxsIVJ0bFVzZXJUaHJlYWRTdGFydCAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXFNZU1RFTTMyXG50
ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzQgIDB4MDAwMDAwMDAw
MDAwMDAwMCBpbiA/PyAoKQ0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KQmFja3Ry
YWNlIHN0b3BwZWQ6IHByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQg
c3RhY2s/KQ0KDQpUaHJlYWQgNCAoVGhyZWFkIDg1NjguMHgxOTMwKToNCiMwICAweDAwMDA3ZmY5
YzhhYTBlM2EgaW4gbnRkbGwhWndSZWFkRmlsZSAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXFNZU1RF
TTMyXG50ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzEgIDB4MDAw
MDdmZjljNWMxODNhOCBpbiBSZWFkRmlsZSAoKSBmcm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJcS2Vy
bmVsQmFzZS5kbGwNCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4NCiMyICAweDAwMDA3
ZmY5Yzg5ODFiNTkgaW4gbXN2Y3J0IV9fY3J0R2V0U3RyaW5nVHlwZVcgKCkNCiAgIGZyb20gQzpc
V0lORE9XU1xzeXN0ZW0zMlxtc3ZjcnQuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFi
bGUuDQojMyAgMHgwMDAwN2ZmOWM4OTgxYzc5IGluIG1zdmNydCFfcmVhZCAoKSBmcm9tIEM6XFdJ
TkRPV1Ncc3lzdGVtMzJcbXN2Y3J0LmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxl
Lg0KIzQgIDB4MDAwMDAwMDQwMDE5NjEzNSBpbiBfc3lzX3JlYWRfYWhlYWQgKGZkPTxvcHRpbWl6
ZWQgb3V0PikNCiAgICBhdCBnOi9lbWFjcy9yZXBvL2VtYWNzL3NyYy93MzIuYzo3OTkwDQogICAg
ICAgIGNwID0gMHgxMDAwMDAwMDANCiAgICAgICAgcmMgPSAwDQojNSAgMHgwMDAwMDAwNDAwMTli
ODE1IGluIHJlYWRlcl90aHJlYWQgKGFyZz0weDQwMTdhNTk0MCA8Y2hpbGRfcHJvY3M+KQ0KICAg
IGF0IGc6L2VtYWNzL3JlcG8vZW1hY3Mvc3JjL3czMnByb2MuYzoxMDE3DQogICAgICAgIHJjID0g
PG9wdGltaXplZCBvdXQ+DQogICAgICAgIGNwID0gMHg0MDE3YTU5NDAgPGNoaWxkX3Byb2NzPg0K
IzYgIDB4MDAwMDdmZjljODgyMTNkMiBpbiBLRVJORUwzMiFCYXNlVGhyZWFkSW5pdFRodW5rICgp
DQogICBmcm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJca2VybmVsMzIuZGxsDQpObyBzeW1ib2wgdGFi
bGUgaW5mbyBhdmFpbGFibGUuDQojNyAgMHgwMDAwN2ZmOWM4YTdlYjY0IGluIG50ZGxsIVJ0bFVz
ZXJUaHJlYWRTdGFydCAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXFNZU1RFTTMyXG50ZGxsLmRsbA0K
Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzggIDB4MDAwMDAwMDAwMDAwMDAwMCBp
biA/PyAoKQ0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KQmFja3RyYWNlIHN0b3Bw
ZWQ6IHByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQ0K
DQpUaHJlYWQgMyAoVGhyZWFkIDg1NjguMHgyMjU4KToNCiMwICAweDAwMDA3ZmY5YzYwNzI2Y2Eg
aW4gVVNFUjMyIUdldE1lc3NhZ2VXICgpDQogICBmcm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJcdXNl
cjMyLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzEgIDB4MDAwMDdmZjlj
NjA3MjY5NSBpbiBVU0VSMzIhR2V0TWVzc2FnZVcgKCkNCiAgIGZyb20gQzpcV0lORE9XU1xzeXN0
ZW0zMlx1c2VyMzIuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojMiAgMHgw
MDAwMDAwNDAwMTcwMDY4IGluIHczMl9tc2dfcHVtcCAobXNnX2J1Zj0weDJlY2ZlZjApDQogICAg
YXQgZzovZW1hY3MvcmVwby9lbWFjcy9zcmMvdzMyZm5zLmM6MjUyNg0KICAgICAgICBtc2cgPSB7
aHduZCA9IDB4MTkwNmQwLCBtZXNzYWdlID0gMjc1LCB3UGFyYW0gPSAxLCBsUGFyYW0gPSAwLA0K
ICAgICAgICAgIHRpbWUgPSA0NTIyOTAwOTMsIHB0ID0ge3ggPSAyNzMsIHkgPSAxMDc1fX0NCiAg
ICAgICAgZm9jdXNfd2luZG93ID0gPG9wdGltaXplZCBvdXQ+DQojMyAgMHgwMDAwMDAwNDAwMTcw
NWMwIGluIHczMl9tc2dfd29ya2VyIChhcmc9PG9wdGltaXplZCBvdXQ+KQ0KLS0tVHlwZSA8cmV0
dXJuPiB0byBjb250aW51ZSwgb3IgcSA8cmV0dXJuPiB0byBxdWl0LS0tDQogICAgYXQgZzovZW1h
Y3MvcmVwby9lbWFjcy9zcmMvdzMyZm5zLmM6Mjc0Nw0KICAgICAgICBtc2cgPSB7aHduZCA9IDB4
MCwgbWVzc2FnZSA9IDAsIHdQYXJhbSA9IDAsIGxQYXJhbSA9IDAsIHRpbWUgPSAwLA0KICAgICAg
ICAgIHB0ID0ge3ggPSAwLCB5ID0gMH19DQogICAgICAgIGR1bW15X2J1ZiA9IHtuZXh0ID0gMHgw
LCB3MzJtc2cgPSB7bXNnID0ge2h3bmQgPSAweDAsIG1lc3NhZ2UgPSAwLA0KICAgICAgICAgICAg
ICB3UGFyYW0gPSAwLCBsUGFyYW0gPSAwLCB0aW1lID0gMCwgcHQgPSB7eCA9IDAsIHkgPSAwfX0s
DQogICAgICAgICAgICBkd01vZGlmaWVycyA9IDAsIHJlY3QgPSB7bGVmdCA9IDAsIHRvcCA9IDAs
IHJpZ2h0ID0gMCwNCiAgICAgICAgICAgICAgYm90dG9tID0gMH19LCByZXN1bHQgPSAwLCBjb21w
bGV0ZWQgPSAwfQ0KIzQgIDB4MDAwMDdmZjljODgyMTNkMiBpbiBLRVJORUwzMiFCYXNlVGhyZWFk
SW5pdFRodW5rICgpDQogICBmcm9tIEM6XFdJTkRPV1Ncc3lzdGVtMzJca2VybmVsMzIuZGxsDQpO
byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojNSAgMHgwMDAwN2ZmOWM4YTdlYjY0IGlu
IG50ZGxsIVJ0bFVzZXJUaHJlYWRTdGFydCAoKQ0KICAgZnJvbSBDOlxXSU5ET1dTXFNZU1RFTTMy
XG50ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzYgIDB4MDAwMDAw
MDAwMDAwMDAwMCBpbiA/PyAoKQ0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KQmFj
a3RyYWNlIHN0b3BwZWQ6IHByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1
cHQgc3RhY2s/KQ0KDQpUaHJlYWQgMiAoVGhyZWFkIDg1NjguMHgxNWE0KToNCiMwICAweDAwMDA3
ZmY5YzhhYTExMWEgaW4gbnRkbGwhWndEZWxheUV4ZWN1dGlvbiAoKQ0KICAgZnJvbSBDOlxXSU5E
T1dTXFNZU1RFTTMyXG50ZGxsLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0K
IzEgIDB4MDAwMDdmZjljNWMxMTIxYSBpbiBTbGVlcEV4ICgpIGZyb20gQzpcV0lORE9XU1xzeXN0
ZW0zMlxLZXJuZWxCYXNlLmRsbA0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLg0KIzIg
IDB4MDAwMDAwMDQwMDE5YmRhYiBpbiB0aW1lcl9sb29wIChhcmc9MHgwKQ0KICAgIGF0IGc6L2Vt
YWNzL3JlcG8vZW1hY3Mvc3JjL3czMnByb2MuYzozODENCiAgICAgICAgc2xlZXBfdGltZSA9IDxv
cHRpbWl6ZWQgb3V0Pg0KICAgICAgICBoYW5kbGVyID0gPG9wdGltaXplZCBvdXQ+DQogICAgICAg
IG5vdyA9IDxvcHRpbWl6ZWQgb3V0Pg0KICAgICAgICBleHBpcmUgPSA8b3B0aW1pemVkIG91dD4N
CiAgICAgICAgcmVsb2FkID0gPG9wdGltaXplZCBvdXQ+DQogICAgICAgIGl0aW1lciA9IDB4MA0K
ICAgICAgICB3aGljaCA9IDxvcHRpbWl6ZWQgb3V0Pg0KICAgICAgICBzaWcgPSA8b3B0aW1pemVk
IG91dD4NCiAgICAgICAgY3JpdCA9IDxvcHRpbWl6ZWQgb3V0Pg0KICAgICAgICBtYXhfc2xlZXAg
PSA8b3B0aW1pemVkIG91dD4NCiAgICAgICAgaHRoID0gMHgwDQojMyAgMHgwMDAwN2ZmOWM4ODIx
M2QyIGluIEtFUk5FTDMyIUJhc2VUaHJlYWRJbml0VGh1bmsgKCkNCiAgIGZyb20gQzpcV0lORE9X
U1xzeXN0ZW0zMlxrZXJuZWwzMi5kbGwNCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4N
CiM0ICAweDAwMDA3ZmY5YzhhN2ViNjQgaW4gbnRkbGwhUnRsVXNlclRocmVhZFN0YXJ0ICgpDQog
ICBmcm9tIEM6XFdJTkRPV1NcU1lTVEVNMzJcbnRkbGwuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5m
byBhdmFpbGFibGUuDQojNSAgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpDQpObyBzeW1ib2wg
dGFibGUgaW5mbyBhdmFpbGFibGUuDQpCYWNrdHJhY2Ugc3RvcHBlZDogcHJldmlvdXMgZnJhbWUg
aW5uZXIgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8pDQoNClRocmVhZCAxIChUaHJlYWQg
ODU2OC4weDEwYzgpOg0KIzAgIDB4MDAwMDdmZjljOGFhMGUxYSBpbiBudGRsbCFad1dhaXRGb3JT
aW5nbGVPYmplY3QgKCkNCiAgIGZyb20gQzpcV0lORE9XU1xTWVNURU0zMlxudGRsbC5kbGwNCk5v
IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4NCiMxICAweDAwMDA3ZmY5YzhhNDlhODUgaW4g
bnRkbGwhUnRsSW1hZ2VOdEhlYWRlckV4ICgpDQogICBmcm9tIEM6XFdJTkRPV1NcU1lTVEVNMzJc
bnRkbGwuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuDQojMiAgMHgwMDAwN2Zm
OWM4YTQ3ZjQ0IGluIG50ZGxsIVJ0bEVudGVyQ3JpdGljYWxTZWN0aW9uICgpDQogICBmcm9tIEM6
XFdJTkRPV1NcU1lTVEVNMzJcbnRkbGwuZGxsDQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFi
bGUuDQpCYWNrdHJhY2Ugc3RvcHBlZDogcHJldmlvdXMgZnJhbWUgaW5uZXIgdG8gdGhpcyBmcmFt
ZSAoY29ycnVwdCBzdGFjaz8pDQooZ2RiKQ0K
--001a1132e9ca271079050f3dbe37--

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 26 Dec 2015 18:11:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 26 13:11:02 2015
Received: from localhost ([127.0.0.1]:42023 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aCtJ0-0005zs-An
	for submit <at> debbugs.gnu.org; Sat, 26 Dec 2015 13:11:02 -0500
Received: from hermes.netfonds.no ([80.91.224.195]:56145)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <larsi@HIDDEN>) id 1aCtIy-0005zb-KY
 for control <at> debbugs.gnu.org; Sat, 26 Dec 2015 13:11:00 -0500
Received: from 2.150.58.24.tmi.telenormobil.no ([2.150.58.24] helo=mouse)
 by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.72) (envelope-from <larsi@HIDDEN>) id 1aCtId-0003F8-FP
 for control <at> debbugs.gnu.org; Sat, 26 Dec 2015 19:10:39 +0100
Date: Sat, 26 Dec 2015 19:10:38 +0100
Message-Id: <87ege9jd29.fsf@HIDDEN>
To: control <at> debbugs.gnu.org
From: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: control message for bug #19868
X-MailScanner-ID: 1aCtId-0003F8-FP
X-Netfonds-MailScanner: Found to be clean
X-Netfonds-MailScanner-From: larsi@HIDDEN
MailScanner-NULL-Check: 1451758240.12563@73XGkp1vIxXjgNAHn39aCw
X-Spam-Status: No
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

tags 19868 - moreinfo

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19868: #19868 25.0.50; Compilation eats buffers
References: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
In-Reply-To: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
Resent-From: Noam Postavsky <npostavs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 12 Aug 2016 20:48:01 +0000
Resent-Message-ID: <handler.19868.B19868.14710348359816 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19868
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 19868 <at> debbugs.gnu.org
Cc: Richard Copley <rcopley@HIDDEN>
Received: via spool by 19868-submit <at> debbugs.gnu.org id=B19868.14710348359816
          (code B ref 19868); Fri, 12 Aug 2016 20:48:01 +0000
Received: (at 19868) by debbugs.gnu.org; 12 Aug 2016 20:47:15 +0000
Received: from localhost ([127.0.0.1]:55462 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bYJMJ-0002YF-7a
	for submit <at> debbugs.gnu.org; Fri, 12 Aug 2016 16:47:15 -0400
Received: from mail-oi0-f52.google.com ([209.85.218.52]:34891)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <npostavs@HIDDEN>) id 1bYJMH-0002Xx-Tm
 for 19868 <at> debbugs.gnu.org; Fri, 12 Aug 2016 16:47:14 -0400
Received: by mail-oi0-f52.google.com with SMTP id 4so49381861oih.2
 for <19868 <at> debbugs.gnu.org>; Fri, 12 Aug 2016 13:47:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:from:date:message-id:subject:to:cc;
 bh=m5ORyNPW/QcR48f0Y3itTg5sUPQ42wzeVSSdgYecs0I=;
 b=w6KU5EGYNBVbPUFj/BFsB8nsP0OEpGJ3JMDk3HmJUr3fx2oih3dtKMXu5ir3s5EGZl
 Id2G7wU0mo3Th+Ex/oKznWtfmoUH7sLARQHT1e2Qk+lLgzZeVrU87GfzYevCFoUarnba
 imKQy+h557UnOKxSWPQSsF4sY//SjI0HLXJF1tEOJH1xNFYE4+blMJZvFSbKhFPwJTxi
 zpz+jDcB9f6ma5FGGJAPV+2p+uxpY69Poam/z9cP2nAiyzRk3q5DAFeRMjIDNXYvPpF1
 jy96FV56zl2GDhqvYA8WuGzDNDNCZ0mhzE7jWJUvjM1sCo6p8qAAeBXirtvrXShBVzDm
 GSJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
 :to:cc;
 bh=m5ORyNPW/QcR48f0Y3itTg5sUPQ42wzeVSSdgYecs0I=;
 b=Hv6TGvuucJabWgSnKyb9g8XXt5oG6onFz2StLYEo1DejDldp3yzw9Vy+q88nLtdAUt
 FubSYtbHGrpR0aCC8AsvOENJvzmsR0wxKRBTkABmvIMBkoZRMcLlp1x8VNUa1HO4LfLr
 Mp7p+nN9y2rQaqpjyuhnPBDsZE7KswK4WtQ3zaV/XDRAIkVV38z4M2mNmAtpxCrJNrbU
 MnClVHqF+B62vE4Ho237WrsUA3KjRz6HoxBlFYz7XdDniY85sEzfpraBvv3UYyIcBifX
 VvKlywvMuCtsqhaZsC5MXngrM9P+m2uy57JVE7vm78H8jMBKyFe+wGCBmZEai+cahRM0
 5DLQ==
X-Gm-Message-State: AEkooutnhtfnBbTEsoaqEbvc2jCxg6AZOK3hH2RPM8OybVFbZ9RLvH11jh6p8d6sbfUz9dqr+bEmzNsKQlJP2w==
X-Received: by 10.202.245.88 with SMTP id t85mr8111280oih.202.1471034828223;
 Fri, 12 Aug 2016 13:47:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.7.200 with HTTP; Fri, 12 Aug 2016 13:47:07 -0700 (PDT)
From: Noam Postavsky <npostavs@HIDDEN>
Date: Fri, 12 Aug 2016 16:47:07 -0400
X-Google-Sender-Auth: 1uoc_YZHdmj63VJUDiB3bpvlRKs
Message-ID: <CAM-tV--EuJiHpdhXba1t1ohkVkDmcOR7h2SdbCob-i1_radspQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

retitle 19868 [w32] restarting compilation hangs trying to kill process
found 19868 25.1
quit

> I tried this on Windows 7 and XP, and both show the same correct
> behavior.
>
> It could be that what you see is specific to Windows 8, or to 64-bit
> programs, or to how MinGW64 sets up the process in its startup code (I
> used MinGW32).
>
> You say above that Emacs hangs inside the delete-process call -- can
> you show a backtrace in that state, preferably from an unoptimized
> build?  I'd like to see where exactly it hangs.

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

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 12 Aug 2016 20:47:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 12 16:47:15 2016
Received: from localhost ([127.0.0.1]:55464 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bYJMJ-0002YI-FL
	for submit <at> debbugs.gnu.org; Fri, 12 Aug 2016 16:47:15 -0400
Received: from mail-oi0-f51.google.com ([209.85.218.51]:34660)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <npostavs@HIDDEN>) id 1bYJMI-0002Xw-0Y
 for control <at> debbugs.gnu.org; Fri, 12 Aug 2016 16:47:14 -0400
Received: by mail-oi0-f51.google.com with SMTP id l203so49491463oib.1
 for <control <at> debbugs.gnu.org>; Fri, 12 Aug 2016 13:47:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:from:date:message-id:subject:to:cc;
 bh=m5ORyNPW/QcR48f0Y3itTg5sUPQ42wzeVSSdgYecs0I=;
 b=w6KU5EGYNBVbPUFj/BFsB8nsP0OEpGJ3JMDk3HmJUr3fx2oih3dtKMXu5ir3s5EGZl
 Id2G7wU0mo3Th+Ex/oKznWtfmoUH7sLARQHT1e2Qk+lLgzZeVrU87GfzYevCFoUarnba
 imKQy+h557UnOKxSWPQSsF4sY//SjI0HLXJF1tEOJH1xNFYE4+blMJZvFSbKhFPwJTxi
 zpz+jDcB9f6ma5FGGJAPV+2p+uxpY69Poam/z9cP2nAiyzRk3q5DAFeRMjIDNXYvPpF1
 jy96FV56zl2GDhqvYA8WuGzDNDNCZ0mhzE7jWJUvjM1sCo6p8qAAeBXirtvrXShBVzDm
 GSJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
 :to:cc;
 bh=m5ORyNPW/QcR48f0Y3itTg5sUPQ42wzeVSSdgYecs0I=;
 b=hxy6mVaCV1Ef+UBgxIHWZUmEKyzlbM5Pmc4gXiHFcym+K5ORJJ+OMPJBflFYne+JEP
 bgf33MAEx19ntRHU+mH9IJMenu+vcZXSVlt9ddM9LXrhsnChHZyZ2imYyr4dmCHXWWWD
 aikAoSAx935bjL6GGNCzrvq/7tlvUeXMN2h7e85qQ/JhXMeeIFkohhqbcamAV3C4Zq/p
 slqfe2A3LC5zgFBmQsDjBL/fIJkM5xr/rjXrSb4VOz9f2QyGxMb1xCzjKwA1AFvaQUPQ
 0uHYCndFkVs5Ii/ac8F+0voiOF2T/sHxyTRaKbgrNDP2mcr6mWcAllFZlCSjQso3KImq
 TqaA==
X-Gm-Message-State: AEkoouuqC7xsUfmdFpaa0CgUWNl4ROYDfphGQJgvilgpYe177btSLGWtvbkKayrf4CYpsiqcEdoCZQ1mHu0lkg==
X-Received: by 10.202.245.88 with SMTP id t85mr8111280oih.202.1471034828223;
 Fri, 12 Aug 2016 13:47:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.7.200 with HTTP; Fri, 12 Aug 2016 13:47:07 -0700 (PDT)
From: Noam Postavsky <npostavs@HIDDEN>
Date: Fri, 12 Aug 2016 16:47:07 -0400
X-Google-Sender-Auth: 1uoc_YZHdmj63VJUDiB3bpvlRKs
Message-ID: <CAM-tV--EuJiHpdhXba1t1ohkVkDmcOR7h2SdbCob-i1_radspQ@HIDDEN>
Subject: #19868 25.0.50; Compilation eats buffers
To: 19868 <at> debbugs.gnu.org
Content-Type: text/plain; charset=UTF-8
Bcc: control <at> debbugs.gnu.org
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: control
Cc: Richard Copley <rcopley@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

retitle 19868 [w32] restarting compilation hangs trying to kill process
found 19868 25.1
quit

> I tried this on Windows 7 and XP, and both show the same correct
> behavior.
>
> It could be that what you see is specific to Windows 8, or to 64-bit
> programs, or to how MinGW64 sets up the process in its startup code (I
> used MinGW32).
>
> You say above that Emacs hangs inside the delete-process call -- can
> you show a backtrace in that state, preferably from an unoptimized
> build?  I'd like to see where exactly it hangs.

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

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 12 Aug 2016 20:47:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 12 16:47:15 2016
Received: from localhost ([127.0.0.1]:55464 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bYJMJ-0002YI-FL
	for submit <at> debbugs.gnu.org; Fri, 12 Aug 2016 16:47:15 -0400
Received: from mail-oi0-f51.google.com ([209.85.218.51]:34660)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <npostavs@HIDDEN>) id 1bYJMI-0002Xw-0Y
 for control <at> debbugs.gnu.org; Fri, 12 Aug 2016 16:47:14 -0400
Received: by mail-oi0-f51.google.com with SMTP id l203so49491463oib.1
 for <control <at> debbugs.gnu.org>; Fri, 12 Aug 2016 13:47:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:from:date:message-id:subject:to:cc;
 bh=m5ORyNPW/QcR48f0Y3itTg5sUPQ42wzeVSSdgYecs0I=;
 b=w6KU5EGYNBVbPUFj/BFsB8nsP0OEpGJ3JMDk3HmJUr3fx2oih3dtKMXu5ir3s5EGZl
 Id2G7wU0mo3Th+Ex/oKznWtfmoUH7sLARQHT1e2Qk+lLgzZeVrU87GfzYevCFoUarnba
 imKQy+h557UnOKxSWPQSsF4sY//SjI0HLXJF1tEOJH1xNFYE4+blMJZvFSbKhFPwJTxi
 zpz+jDcB9f6ma5FGGJAPV+2p+uxpY69Poam/z9cP2nAiyzRk3q5DAFeRMjIDNXYvPpF1
 jy96FV56zl2GDhqvYA8WuGzDNDNCZ0mhzE7jWJUvjM1sCo6p8qAAeBXirtvrXShBVzDm
 GSJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
 :to:cc;
 bh=m5ORyNPW/QcR48f0Y3itTg5sUPQ42wzeVSSdgYecs0I=;
 b=hxy6mVaCV1Ef+UBgxIHWZUmEKyzlbM5Pmc4gXiHFcym+K5ORJJ+OMPJBflFYne+JEP
 bgf33MAEx19ntRHU+mH9IJMenu+vcZXSVlt9ddM9LXrhsnChHZyZ2imYyr4dmCHXWWWD
 aikAoSAx935bjL6GGNCzrvq/7tlvUeXMN2h7e85qQ/JhXMeeIFkohhqbcamAV3C4Zq/p
 slqfe2A3LC5zgFBmQsDjBL/fIJkM5xr/rjXrSb4VOz9f2QyGxMb1xCzjKwA1AFvaQUPQ
 0uHYCndFkVs5Ii/ac8F+0voiOF2T/sHxyTRaKbgrNDP2mcr6mWcAllFZlCSjQso3KImq
 TqaA==
X-Gm-Message-State: AEkoouuqC7xsUfmdFpaa0CgUWNl4ROYDfphGQJgvilgpYe177btSLGWtvbkKayrf4CYpsiqcEdoCZQ1mHu0lkg==
X-Received: by 10.202.245.88 with SMTP id t85mr8111280oih.202.1471034828223;
 Fri, 12 Aug 2016 13:47:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.7.200 with HTTP; Fri, 12 Aug 2016 13:47:07 -0700 (PDT)
From: Noam Postavsky <npostavs@HIDDEN>
Date: Fri, 12 Aug 2016 16:47:07 -0400
X-Google-Sender-Auth: 1uoc_YZHdmj63VJUDiB3bpvlRKs
Message-ID: <CAM-tV--EuJiHpdhXba1t1ohkVkDmcOR7h2SdbCob-i1_radspQ@HIDDEN>
Subject: #19868 25.0.50; Compilation eats buffers
To: 19868 <at> debbugs.gnu.org
Content-Type: text/plain; charset=UTF-8
Bcc: control <at> debbugs.gnu.org
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: control
Cc: Richard Copley <rcopley@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

retitle 19868 [w32] restarting compilation hangs trying to kill process
found 19868 25.1
quit

> I tried this on Windows 7 and XP, and both show the same correct
> behavior.
>
> It could be that what you see is specific to Windows 8, or to 64-bit
> programs, or to how MinGW64 sets up the process in its startup code (I
> used MinGW32).
>
> You say above that Emacs hangs inside the delete-process call -- can
> you show a backtrace in that state, preferably from an unoptimized
> build?  I'd like to see where exactly it hangs.

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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19868: #19868 25.0.50; Compilation eats buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 13 Aug 2016 06:45:02 +0000
Resent-Message-ID: <handler.19868.B19868.147107069025416 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19868
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Noam Postavsky <npostavs@HIDDEN>
Cc: rcopley@HIDDEN, 19868 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 19868-submit <at> debbugs.gnu.org id=B19868.147107069025416
          (code B ref 19868); Sat, 13 Aug 2016 06:45:02 +0000
Received: (at 19868) by debbugs.gnu.org; 13 Aug 2016 06:44:50 +0000
Received: from localhost ([127.0.0.1]:55648 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bYSgb-0006bs-QH
	for submit <at> debbugs.gnu.org; Sat, 13 Aug 2016 02:44:49 -0400
Received: from eggs.gnu.org ([208.118.235.92]:44345)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bYSgZ-0006bg-NM
 for 19868 <at> debbugs.gnu.org; Sat, 13 Aug 2016 02:44:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bYSgT-0005vp-IN
 for 19868 <at> debbugs.gnu.org; Sat, 13 Aug 2016 02:44:42 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58851)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bYSgP-0005vH-OA; Sat, 13 Aug 2016 02:44:37 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4389
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bYSgN-0005qA-9E; Sat, 13 Aug 2016 02:44:35 -0400
Date: Sat, 13 Aug 2016 09:44:29 +0300
Message-Id: <83h9apdv76.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CAM-tV--EuJiHpdhXba1t1ohkVkDmcOR7h2SdbCob-i1_radspQ@HIDDEN>
 (message from Noam Postavsky on Fri, 12 Aug 2016 16:47:07 -0400)
References: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
 <CAM-tV--EuJiHpdhXba1t1ohkVkDmcOR7h2SdbCob-i1_radspQ@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.5 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.5 (-----)

> From: Noam Postavsky <npostavs@HIDDEN>
> Date: Fri, 12 Aug 2016 16:47:07 -0400
> Cc: Richard Copley <rcopley@HIDDEN>
> 
> 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?

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.

In any case, this is a tricky situation, because we kill the shell,
not the program it runs.  When the program run from the shell was
built with -mwindows, it is detached from the shell, and the various
Emacs facilities that try to kill subprocesses are likely to fail in
exciting ways.

IOW, running -mwindows programs from the likes of "M-x compile" is not
really supported on MS-Windows, I think.  Of course, if we can figure
out how to avoid the hang in this case, we should.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19868: #19868 25.0.50; Compilation eats buffers
Resent-From: Noam Postavsky <npostavs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 15 Aug 2016 22:20:01 +0000
Resent-Message-ID: <handler.19868.B19868.14712995521687 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19868
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Richard Copley <rcopley@HIDDEN>, 19868 <at> debbugs.gnu.org
Received: via spool by 19868-submit <at> debbugs.gnu.org id=B19868.14712995521687
          (code B ref 19868); Mon, 15 Aug 2016 22:20:01 +0000
Received: (at 19868) by debbugs.gnu.org; 15 Aug 2016 22:19:12 +0000
Received: from localhost ([127.0.0.1]:58608 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bZQDw-0000R9-25
	for submit <at> debbugs.gnu.org; Mon, 15 Aug 2016 18:19:12 -0400
Received: from mail-oi0-f48.google.com ([209.85.218.48]:33307)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <npostavs@HIDDEN>) id 1bZQDv-0000Qy-DA
 for 19868 <at> debbugs.gnu.org; Mon, 15 Aug 2016 18:19:11 -0400
Received: by mail-oi0-f48.google.com with SMTP id c15so77139986oig.0
 for <19868 <at> debbugs.gnu.org>; Mon, 15 Aug 2016 15:19:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:in-reply-to:references:from:date:message-id
 :subject:to:cc;
 bh=hddMZ/RFGvJyRceXg3ZgEgB7ftTxkizFxkhbeAVKq3w=;
 b=bT2Bf5ETenlaA+d9dW+ioRjTb3p1pL572Q6O+aCzg4OHEyLS/1utesLk2laqztn19p
 0o7hNRWMttoaUBKWZpdTP2UFE+eOWt5vcITu06MnPr+J9YR1l6REyldHqc0OfPK+GN7h
 Wr+dMSZYWzWj3kn/RznhUhCf/gWjFnDIv782Lif2mK1aeBlWSUbHJNlw/+jRJe8QXm4X
 5neiNmKlx1gXxJs1f8nQ7WsY/gnWA0lMkxKWidyd4YnIycBojGq1szDeA8tthZ7ioDKO
 xfEMVkBR9HB9JTYSDHOAMw9xo/FAnO2xmG9wHkdvbY6/LLhBc/anoSxFe8I1iRw0f3Wj
 JF6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
 :date:message-id:subject:to:cc;
 bh=hddMZ/RFGvJyRceXg3ZgEgB7ftTxkizFxkhbeAVKq3w=;
 b=PW4LyLxjFJpCewTy7Qu9lMU5M6kCWqdLENj5xpQ8/yvrQRzKrrx6b63vKFr6qif72p
 cJz7bihgTJMeESBNDSkNLeoI+RfUUZ/z0NmFDBdo5XnPjApkf1Ber5O8sSQKmmOHs0iJ
 4vQxgtpuyEzBWquWWI9NklJsoJ+zxTkDEbwjKzFAwSEktw34JHakZ3fx0gO0RvkjBj++
 r7vTheTWiXP2tmcGKkyHK0LQHn7J3pUfeFdMIXc5wYhhoDwzTlRiK8rN7WZ0SiSEuG1x
 IPxo2mV+diIl5CXSDcm40ZCuRi3w6v3hjGMqKUACtG8lBp/kyJbNPJ9kkC6/UXJD0YtI
 s44w==
X-Gm-Message-State: AEkoouuzdZM58tsTlffUCnDVKjPROjUBTJoK6Dlr+6CylLEmTFyoj7c8V8FyUBPKYiPKmjYV9Tr/JRfafnGCYw==
X-Received: by 10.157.37.241 with SMTP id q104mr14588231ota.112.1471299545750; 
 Mon, 15 Aug 2016 15:19:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.7.200 with HTTP; Mon, 15 Aug 2016 15:19:05 -0700 (PDT)
In-Reply-To: <83h9apdv76.fsf@HIDDEN>
References: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
 <CAM-tV--EuJiHpdhXba1t1ohkVkDmcOR7h2SdbCob-i1_radspQ@HIDDEN>
 <83h9apdv76.fsf@HIDDEN>
From: Noam Postavsky <npostavs@HIDDEN>
Date: Mon, 15 Aug 2016 18:19:05 -0400
X-Google-Sender-Auth: PWRuuVOTxZPtZbjX0xAdSlt98tg
Message-ID: <CAM-tV-8Xk3T0Muxp-bio4PeaUZx1Ry2yCZmmekcrh8NvS4NgSg@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

On Sat, Aug 13, 2016 at 2:44 AM, Eli Zaretskii <eliz@HIDDEN> wrote:
>> From: Noam Postavsky <npostavs@HIDDEN>
>> Date: Fri, 12 Aug 2016 16:47:07 -0400
>> Cc: Richard Copley <rcopley@HIDDEN>
>>
>> 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.

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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19868: #19868 25.0.50; Compilation eats buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 16 Aug 2016 14:19:02 +0000
Resent-Message-ID: <handler.19868.B19868.147135711523900 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19868
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Noam Postavsky <npostavs@HIDDEN>
Cc: rcopley@HIDDEN, 19868 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 19868-submit <at> debbugs.gnu.org id=B19868.147135711523900
          (code B ref 19868); Tue, 16 Aug 2016 14:19:02 +0000
Received: (at 19868) by debbugs.gnu.org; 16 Aug 2016 14:18:35 +0000
Received: from localhost ([127.0.0.1]:59364 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bZfCN-0006DO-82
	for submit <at> debbugs.gnu.org; Tue, 16 Aug 2016 10:18:35 -0400
Received: from eggs.gnu.org ([208.118.235.92]:50652)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1bZfCK-0006DA-Ta
 for 19868 <at> debbugs.gnu.org; Tue, 16 Aug 2016 10:18:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1bZfCE-0004IZ-UF
 for 19868 <at> debbugs.gnu.org; Tue, 16 Aug 2016 10:18:27 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52233)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1bZfCA-0004HF-Dp; Tue, 16 Aug 2016 10:18:22 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2510
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1bZfC7-0003Ym-HB; Tue, 16 Aug 2016 10:18:20 -0400
Date: Tue, 16 Aug 2016 17:18:16 +0300
Message-Id: <83h9akg5lj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CAM-tV-8Xk3T0Muxp-bio4PeaUZx1Ry2yCZmmekcrh8NvS4NgSg@HIDDEN>
 (message from Noam Postavsky on Mon, 15 Aug 2016 18:19:05 -0400)
References: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
 <CAM-tV--EuJiHpdhXba1t1ohkVkDmcOR7h2SdbCob-i1_radspQ@HIDDEN>
 <83h9apdv76.fsf@HIDDEN>
 <CAM-tV-8Xk3T0Muxp-bio4PeaUZx1Ry2yCZmmekcrh8NvS4NgSg@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.6 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.6 (-----)

> From: Noam Postavsky <npostavs@HIDDEN>
> Date: Mon, 15 Aug 2016 18:19:05 -0400
> Cc: 19868 <at> debbugs.gnu.org, Richard Copley <rcopley@HIDDEN>
> 
> On Sat, Aug 13, 2016 at 2:44 AM, Eli Zaretskii <eliz@HIDDEN> wrote:
> >> From: Noam Postavsky <npostavs@HIDDEN>
> >> Date: Fri, 12 Aug 2016 16:47:07 -0400
> >> Cc: Richard Copley <rcopley@HIDDEN>
> >>
> >> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19868: #19868 25.0.50; Compilation eats buffers
Resent-From: Noam Postavsky <npostavs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 16 Aug 2016 21:18:02 +0000
Resent-Message-ID: <handler.19868.B19868.147138224910252 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19868
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Richard Copley <rcopley@HIDDEN>, 19868 <at> debbugs.gnu.org
Received: via spool by 19868-submit <at> debbugs.gnu.org id=B19868.147138224910252
          (code B ref 19868); Tue, 16 Aug 2016 21:18:02 +0000
Received: (at 19868) by debbugs.gnu.org; 16 Aug 2016 21:17:29 +0000
Received: from localhost ([127.0.0.1]:59544 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bZljk-0002fH-Lv
	for submit <at> debbugs.gnu.org; Tue, 16 Aug 2016 17:17:28 -0400
Received: from mail-oi0-f47.google.com ([209.85.218.47]:35316)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <npostavs@HIDDEN>) id 1bZlji-0002f4-Gh
 for 19868 <at> debbugs.gnu.org; Tue, 16 Aug 2016 17:17:27 -0400
Received: by mail-oi0-f47.google.com with SMTP id 4so116068799oih.2
 for <19868 <at> debbugs.gnu.org>; Tue, 16 Aug 2016 14:17:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:in-reply-to:references:from:date:message-id
 :subject:to:cc;
 bh=0XbI+chVU019PEGLxeWpzMRHtU5oEp/lGzhW4kUgNUY=;
 b=EXVekvBc7UfRfFi8wnQtMwTkIKt8oDBqB0E8042UJWHGxAyN+1umliKvlughDS1usa
 8gWJ4IM/HULTAB9vD6vLGqkrxF3uITWV3ZQ3/kRjqV4xnSHvxx5M+R4AAjx1Wtfo8ZNb
 XBHUdIzbvdDLtkETJDES4cNrTgoaD7Oqdphnfqtb4PAJKsaB2yGjwbHauWkVzlOpTw7J
 fsue0sIJn42EP3a+INywVyRnKRE8njNkIzCUWCH7LMHsB5oMDG3vh5N8/PEaoatXKdcP
 3XFGO9zOi+vMZ5L3qOZb/c7OL+uP/gL9ZwhXOVYYTsVC5XyGIsaiJR9hmo+cxTGEv2QJ
 f+fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
 :date:message-id:subject:to:cc;
 bh=0XbI+chVU019PEGLxeWpzMRHtU5oEp/lGzhW4kUgNUY=;
 b=Fzt4sXhobJZ18qv9PvLUx2HHIxlRvVPttWveH6IK2P/bMty7kf+0PO36lUHMluMP1S
 9P4Aaeop6T7Bi52ILGSVKqEMuC4SfPR55GppDxI7wzGhnmDbctUBO4SMWsHBLP8LiA5e
 yLL0jky8UpLSqOxY4QGbF89T7a7qqz8E/PQBdwHX0mUwqOHeJM9R/6YKQ5XYqpvVn07W
 QzSBjQqDXQQOF+eXsJzhQ9ZLSNRc4FPAK3uXGwnhfTj5O2NiYTMa5OZduwu4sD6kNfUB
 8r1T2ZqZ3K94cau52Qoi4tYz/8ig6h6XU3ral3ceSnPBURuwxwI6fAEdKCIt8rjzv4Tq
 YsLw==
X-Gm-Message-State: AEkooutEJbCPPStgYKt0jduC+nUYvjSrzwxfCPenD6ErPf2fumrxeH/jxCmflpfCarIraSZeqWMtS3udqbGrNQ==
X-Received: by 10.157.36.6 with SMTP id p6mr260780ota.124.1471382240961; Tue,
 16 Aug 2016 14:17:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.7.200 with HTTP; Tue, 16 Aug 2016 14:17:20 -0700 (PDT)
In-Reply-To: <83h9akg5lj.fsf@HIDDEN>
References: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
 <CAM-tV--EuJiHpdhXba1t1ohkVkDmcOR7h2SdbCob-i1_radspQ@HIDDEN>
 <83h9apdv76.fsf@HIDDEN>
 <CAM-tV-8Xk3T0Muxp-bio4PeaUZx1Ry2yCZmmekcrh8NvS4NgSg@HIDDEN>
 <83h9akg5lj.fsf@HIDDEN>
From: Noam Postavsky <npostavs@HIDDEN>
Date: Tue, 16 Aug 2016 17:17:20 -0400
X-Google-Sender-Auth: cHwvyN3iUa2b6wvFixJztMzMzoY
Message-ID: <CAM-tV-8fhbP29wT1tWkedXce4av4qDWQjHCMUbOXQ_bDS7yrvQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19868: #19868 25.0.50; Compilation eats buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 17 Aug 2016 15:16:02 +0000
Resent-Message-ID: <handler.19868.B19868.147144695112851 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19868
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Noam Postavsky <npostavs@HIDDEN>
Cc: rcopley@HIDDEN, 19868 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 19868-submit <at> debbugs.gnu.org id=B19868.147144695112851
          (code B ref 19868); Wed, 17 Aug 2016 15:16:02 +0000
Received: (at 19868) by debbugs.gnu.org; 17 Aug 2016 15:15:51 +0000
Received: from localhost ([127.0.0.1]:60397 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ba2ZL-0003LC-1F
	for submit <at> debbugs.gnu.org; Wed, 17 Aug 2016 11:15:51 -0400
Received: from eggs.gnu.org ([208.118.235.92]:55810)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1ba2ZJ-0003Kz-15
 for 19868 <at> debbugs.gnu.org; Wed, 17 Aug 2016 11:15:49 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1ba2ZC-0007Wz-Cj
 for 19868 <at> debbugs.gnu.org; Wed, 17 Aug 2016 11:15:43 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41372)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1ba2Z8-0007VL-2h; Wed, 17 Aug 2016 11:15:38 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1464
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1ba2Z6-0004pH-8T; Wed, 17 Aug 2016 11:15:36 -0400
Date: Wed, 17 Aug 2016 18:15:39 +0300
Message-Id: <834m6jfmuc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CAM-tV-8fhbP29wT1tWkedXce4av4qDWQjHCMUbOXQ_bDS7yrvQ@HIDDEN>
 (message from Noam Postavsky on Tue, 16 Aug 2016 17:17:20 -0400)
References: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
 <CAM-tV--EuJiHpdhXba1t1ohkVkDmcOR7h2SdbCob-i1_radspQ@HIDDEN>
 <83h9apdv76.fsf@HIDDEN>
 <CAM-tV-8Xk3T0Muxp-bio4PeaUZx1Ry2yCZmmekcrh8NvS4NgSg@HIDDEN>
 <83h9akg5lj.fsf@HIDDEN>
 <CAM-tV-8fhbP29wT1tWkedXce4av4qDWQjHCMUbOXQ_bDS7yrvQ@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.6 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.6 (-----)

> From: Noam Postavsky <npostavs@HIDDEN>
> Date: Tue, 16 Aug 2016 17:17:20 -0400
> Cc: 19868 <at> debbugs.gnu.org, Richard Copley <rcopley@HIDDEN>
> 
> >> 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.

OK.

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

The last sentence shows an important difference between the two
cases.  Can you spot the code which makes the 2 handles -1 in the case
of a console (not -mwindows) application?  That might give us a clue
about the reason for Emacs hanging in _close.

One possibility is that the reader thread is trying to read from the
descriptor which we are trying to close.  Maybe that prevents _close
from completing its job.  Then the question is how does this succeed
in the case of a console application?

compilation-start sends SIGINT to the subprocess, then waits for 1
sec, then calls delete-process.  On Windows, interrupting a process is
implemented in w32proc.c:sys_kill.  My guess is that with a console
application, sending the simulated Ctrl-C to cmdproxy kills both
cmdproxy and the application, while in the -mwindows case only
cmdproxy (and perhaps its child cmd.exe) is killed.  But the details
still evade me: how would the above explain the fact that the
descriptors are already -1 when deactivate_process is called, who
closes them, and by what trigger?

Another thing to try is to set w32-start-process-share-console to a
non-nil value.  I don't know if it will help or make things worse, I
think this option was never seriously used, and I don't know what GUI
applications do on Windows when their control handler function is
called.  MSDN says in
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683155(v=vs.85).aspx:

  All console processes have a default handler function that calls the
  ExitProcess function.

which says nothing about non-console applications.  And I think
non-console applications are not attached to any console anyway, so
this option will probably do nothing useful.  Still, it could give us
some clues about what's going on.

Some more interesting (though very vague) documentation is here:

 https://msdn.microsoft.com/en-us/library/windows/desktop/ms686016(v=vs.85).aspx

> 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).

That's just another manifestation of the fact that we cannot reliably
kill grandchildren processes on MS-Windows, especially when they are
not console applications.  We can only kill the immediate child
process, in this case cmdproxy (and probably its child cmd.exe as
well).

Thanks.

P.S. Don't hesitate to ask questions about how this stuff works, if
something is unclear.  There's a large comment around line 390 in
w32proc.c which provides an overview, so if you didn't already read
it, it could help.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#19868: #19868 25.0.50; Compilation eats buffers
Resent-From: Noam Postavsky <npostavs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 29 Aug 2016 21:49:01 +0000
Resent-Message-ID: <handler.19868.B19868.14725073187818 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 19868
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Richard Copley <rcopley@HIDDEN>, 19868 <at> debbugs.gnu.org
Received: via spool by 19868-submit <at> debbugs.gnu.org id=B19868.14725073187818
          (code B ref 19868); Mon, 29 Aug 2016 21:49:01 +0000
Received: (at 19868) by debbugs.gnu.org; 29 Aug 2016 21:48:38 +0000
Received: from localhost ([127.0.0.1]:43870 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1beUQ1-000222-UW
	for submit <at> debbugs.gnu.org; Mon, 29 Aug 2016 17:48:38 -0400
Received: from mail-oi0-f43.google.com ([209.85.218.43]:34162)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <npostavs@HIDDEN>) id 1beUQ0-00021o-PY
 for 19868 <at> debbugs.gnu.org; Mon, 29 Aug 2016 17:48:37 -0400
Received: by mail-oi0-f43.google.com with SMTP id l203so1270179oib.1
 for <19868 <at> debbugs.gnu.org>; Mon, 29 Aug 2016 14:48:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:in-reply-to:references:from:date:message-id
 :subject:to:cc;
 bh=/L1SMi5B3KgagAIJZK5nEllNwGa1F0xYxV9H9N7RW0M=;
 b=w0lKqM0bghSdFzA+ZLCaqpS5MAaCGrtl+RweuUKerIXxzSg9lsRZsFuD4xTaanFBSW
 rIFYVkcjdJ3ph6rJCzgPkfTfUa4IW1hrlDVd0uE8AzqUEtzYdARvVv1paGRyIi8HVT9K
 25JsJs8lDmDME4XpbT6s8R3+xFfNB8JOlwXh0MeqerOEOfFwM3feah80wftMSKt9Fdq/
 lCTiEpvdYzHwfrfMleic1hVnzKe+tgCjbKjvJlo56c9tphWXAoYIftroBIiyBIO6t3Ka
 TVv8JTCyXG1YyNzU+0G+7Uf5pocjLm820TRPL0uZMRNKm5TQVZ92rq/xK3UWAQrISFCT
 k6Zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
 :date:message-id:subject:to:cc;
 bh=/L1SMi5B3KgagAIJZK5nEllNwGa1F0xYxV9H9N7RW0M=;
 b=Lv5qG4eKPxFkYLBPpJSnLyqXHkeWAXrfZSkDBoaGn53oYR7BFV3yKgftp7VwKXSVxK
 voqwH3NpbQZOn0ifyzYwsgH8qsqt4t5vRiTXGjhY4rS90AXn6TdwdQ8t96v1fcOz0FKb
 sn3LtLxKYBGzN5xlT5ubSugHFz1Znmdl6Hyx/75flmxdEt5/x8vDgFNDomlihx3NToXy
 aT7cdyPhChc7DtncJhZUP9GINP4Q47B8QoxeWVjbN2JtlMQ1LZtIIfyDoGEywFiwqTun
 ewpFbChWyBlb/AwFCtO05KGObNUq09j7/tYNTzjae5FWPfFUuOh5GX18XxpmqzsSzn9N
 nfOg==
X-Gm-Message-State: AE9vXwM9SnJyUUgGSuZd2bmzHs+w/PVmzqtsQQ4iHQr+D0x1Iy7yTQEda5mK+EU53O/hERr90ib9y6u0GivS0Q==
X-Received: by 10.157.17.97 with SMTP id p30mr229423otp.196.1472507310971;
 Mon, 29 Aug 2016 14:48:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.11.125 with HTTP; Mon, 29 Aug 2016 14:48:30 -0700 (PDT)
In-Reply-To: <834m6jfmuc.fsf@HIDDEN>
References: <CAPM58oixb1qR=iAQ9O+ZYAJObYohWBNCTV_5rBajzY60LArjOg@HIDDEN>
 <CAM-tV--EuJiHpdhXba1t1ohkVkDmcOR7h2SdbCob-i1_radspQ@HIDDEN>
 <83h9apdv76.fsf@HIDDEN>
 <CAM-tV-8Xk3T0Muxp-bio4PeaUZx1Ry2yCZmmekcrh8NvS4NgSg@HIDDEN>
 <83h9akg5lj.fsf@HIDDEN>
 <CAM-tV-8fhbP29wT1tWkedXce4av4qDWQjHCMUbOXQ_bDS7yrvQ@HIDDEN>
 <834m6jfmuc.fsf@HIDDEN>
From: Noam Postavsky <npostavs@HIDDEN>
Date: Mon, 29 Aug 2016 17:48:30 -0400
X-Google-Sender-Auth: ZE9vAyZybetXDzrnfNU1Hxb-rs0
Message-ID: <CAM-tV--Ls1oZp0i9ssYxQMYxHpmc10w7+Ci=_xs4-j6Oj-v3hg@HIDDEN>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

On Wed, Aug 17, 2016 at 11:15 AM, Eli Zaretskii <eliz@HIDDEN> wrote:
>> 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.
>
> The last sentence shows an important difference between the two
> cases.  Can you spot the code which makes the 2 handles -1 in the case
> of a console (not -mwindows) application?  That might give us a clue
> about the reason for Emacs hanging in _close.

Sorry, turns out I lied about this. In the non-mwindows case
deactivate_process() gets called 3 times in total, the latter 2 times
have all the handles closed and set to -1 (and I mistakenly looked at
the values only from the last call). The first time is the same as the
mwindows case (except for the hanging, of course).

> Another thing to try is to set w32-start-process-share-console to a
> non-nil value.

Seems to make no difference.

>> 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).
>
> That's just another manifestation of the fact that we cannot reliably
> kill grandchildren processes on MS-Windows, especially when they are
> not console applications.  We can only kill the immediate child
> process, in this case cmdproxy (and probably its child cmd.exe as
> well).

Right, I recall seeing in #15983 a suggestion to crawl the process
tree in order to be able to do this. Another possibility I found while
searching the web is to use Job Objects for this
(https://msdn.microsoft.com/en-us/library/ms684161(VS.85).aspx).
Though it has a limitation:

Windows 7, Windows Server 2008 R2, Windows XP with SP3, Windows Server
2008, Windows Vista and Windows Server 2003:  A process can be
associated with only one job. Jobs cannot be nested. The ability to
nest jobs was added in Windows 8 and Windows Server 2012.

So Emacs using Job Objects would prevent the process it calls from
using them (on older Windows OSes).

>
> P.S. Don't hesitate to ask questions about how this stuff works, if
> something is unclear.  There's a large comment around line 390 in
> w32proc.c which provides an overview, so if you didn't already read
> it, it could help.

For the record, the comment seems to be closer to line 790 (after the first ^L).

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.