From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19868: 25.0.50; Compilation eats buffers Date: Sun, 15 Feb 2015 19:53:16 +0200 Message-ID: <83k2zjukmr.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1424022870 1821 80.91.229.3 (15 Feb 2015 17:54:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Feb 2015 17:54:30 +0000 (UTC) Cc: 19868@debbugs.gnu.org To: Richard Copley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 15 18:54:17 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YN3OY-0004AX-T8 for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Feb 2015 18:54:15 +0100 Original-Received: from localhost ([::1]:36135 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN3OY-00063R-Cs for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Feb 2015 12:54:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN3OR-00062U-0x for bug-gnu-emacs@gnu.org; Sun, 15 Feb 2015 12:54:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YN3OM-000712-4r for bug-gnu-emacs@gnu.org; Sun, 15 Feb 2015 12:54:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN3OM-00070t-1p for bug-gnu-emacs@gnu.org; Sun, 15 Feb 2015 12:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YN3OL-0005kl-NB for bug-gnu-emacs@gnu.org; Sun, 15 Feb 2015 12:54:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Feb 2015 17:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19868 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19868-submit@debbugs.gnu.org id=B19868.142402280222069 (code B ref 19868); Sun, 15 Feb 2015 17:54:01 +0000 Original-Received: (at 19868) by debbugs.gnu.org; 15 Feb 2015 17:53:22 +0000 Original-Received: from localhost ([127.0.0.1]:44897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YN3Ni-0005js-5y for submit@debbugs.gnu.org; Sun, 15 Feb 2015 12:53:22 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:33066) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YN3Ne-0005jd-Uf for 19868@debbugs.gnu.org; Sun, 15 Feb 2015 12:53:20 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NJT00800QQTMI00@mtaout28.012.net.il> for 19868@debbugs.gnu.org; Sun, 15 Feb 2015 19:51:32 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJT006X3QXW6X20@mtaout28.012.net.il>; Sun, 15 Feb 2015 19:51:32 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:99440 Archived-At: > Date: Sat, 14 Feb 2015 19:30:45 +0000 > From: Richard Copley > > On Windows, with MinGW gcc.exe installed and on the path, save a file > "c:\temp\bug.c" containing these two lines: > > #include > 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.)