bug#19868: 25.0.50; Compilation eats buffers

[Eli Zaretskii]

> Date: Sat, 14 Feb 2015 19:30:45 +0000
> From: Richard Copley <rcopley@gmail.com>
> 
> 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.)