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#9087: Crash reading from minibuffer with icomplete-mode Date: Sat, 07 Jan 2012 16:59:18 +0200 Message-ID: <83lipjftix.fsf@gnu.org> References: <83zkkfhk4c.fsf@gnu.org> <871uwng399.fsf@stupidchicken.com> <87obunjg5w.wl%claudio.bley@gmail.com> <83vcovqeu2.fsf@gnu.org> <84ty4ef5ap.wl%claudio.bley@gmail.com> <83vcopno6r.fsf@gnu.org> <83lipkoo60.fsf@gnu.org> <4F071C36.9020401@gmx.at> <83aa60odt9.fsf@gnu.org> <4F074F3F.9030502@gmx.at> <8362goobf6.fsf@gnu.org> <831urco8rt.fsf@gnu.org> <837h13hq17.fsf@gnu.org> <4F081A6D.30508@gmx.at> <831urbhjmz.fsf@gnu.org> <4F0831DD.7050504@gmx.at> <83vcong0tx.fsf@gnu.org> <4F084F4B.8040700@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1325948413 12257 80.91.229.12 (7 Jan 2012 15:00:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 7 Jan 2012 15:00:13 +0000 (UTC) Cc: claudio.bley@gmail.com, lekktu@gmail.com, 9087@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 07 16:00:05 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RjXkb-0001qG-1Z for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Jan 2012 16:00:05 +0100 Original-Received: from localhost ([::1]:50522 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjXka-0006NI-JC for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Jan 2012 10:00:04 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:55350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjXkX-0006Lv-Cz for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2012 10:00:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjXkW-00014l-6D for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2012 10:00:01 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjXkW-00014f-2m for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2012 10:00:00 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RjXkY-0008GS-81 for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2012 10:00:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Jan 2012 15:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9087 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9087-submit@debbugs.gnu.org id=B9087.132594837231703 (code B ref 9087); Sat, 07 Jan 2012 15:00:02 +0000 Original-Received: (at 9087) by debbugs.gnu.org; 7 Jan 2012 14:59:32 +0000 Original-Received: from localhost ([127.0.0.1]:49072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RjXk4-0008FH-D0 for submit@debbugs.gnu.org; Sat, 07 Jan 2012 09:59:32 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:43093) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RjXk1-0008F5-4l for 9087@debbugs.gnu.org; Sat, 07 Jan 2012 09:59:30 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LXF00C00O3MJ900@a-mtaout20.012.net.il> for 9087@debbugs.gnu.org; Sat, 07 Jan 2012 16:59:20 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.229.156.26]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LXF00BVDOAUELL0@a-mtaout20.012.net.il>; Sat, 07 Jan 2012 16:59:20 +0200 (IST) In-reply-to: <4F084F4B.8040700@gmx.at> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:55509 Archived-At: > Date: Sat, 07 Jan 2012 14:57:31 +0100 > From: martin rudalics > CC: monnier@iro.umontreal.ca, jasonr@gnu.org, claudio.bley@gmail.com, > lekktu@gmail.com, 9087@debbugs.gnu.org > > >> > You can verify yourself that, in Emacs without > >> > the patch I sent, typing C-g when triggerbug.el says "now!" does not > >> > cause a crash, but a "Quit", albeit a slightly (by 1-2 seconds on my > >> > box) delayed one. > >> > >> Because `signal' resets immediate_quit to zero? > > > > You mean, as explanation of the delay? > > No. I meant as an explanation of the non-crash. > > > No, I don't think so. I think > > Emacs simply doesn't see C-g until the lengthy calculation is over. > > Likely. But where is C-g treated differently from other input? Here: static void post_character_message (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam, DWORD modifiers) { W32Msg wmsg; wmsg.dwModifiers = modifiers; /* Detect quit_char and set quit-flag directly. Note that we still need to post a message to ensure the main thread will be woken up if blocked in sys_select, but we do NOT want to post the quit_char message itself (because it will usually be as if the user had typed quit_char twice). Instead, we post a dummy message that has no particular effect. */ { int c = wParam; if (isalpha (c) && wmsg.dwModifiers == ctrl_modifier) c = make_ctrl_char (c) & 0377; if (c == quit_char || (wmsg.dwModifiers == 0 && w32_quit_key && wParam == w32_quit_key)) { Vquit_flag = Qt; /* The choice of message is somewhat arbitrary, as long as the main thread handler just ignores it. */ msg = WM_NULL; /* Interrupt any blocking system calls. */ signal_quit (); /* As a safety precaution, forcibly complete any deferred messages. This is a kludge, but I don't see any particularly clean way to handle the situation where a deferred message is "dropped" in the lisp thread, and will thus never be completed, eg. by the user trying to activate the menubar when the lisp thread is busy, and then typing C-g when the menubar doesn't open promptly (with the result that the menubar never responds at all because the deferred WM_INITMENU message is never completed). Another problem situation is when the lisp thread calls SendMessage (to send a window manager command) when a message has been deferred; the lisp thread gets blocked indefinitely waiting for the deferred message to be completed, which itself is waiting for the lisp thread to respond. Note that we don't want to block the input thread waiting for a response from the lisp thread (although that would at least solve the deadlock problem above), because we want to be able to receive C-g to interrupt the lisp thread. */ cancel_all_deferred_msgs (); } else signal_user_input (); } my_post_msg (&wmsg, hwnd, msg, wParam, lParam); } And signal_user_input then does: static void signal_user_input (void) { /* Interrupt any lisp that wants to be interrupted by input. */ if (!NILP (Vthrow_on_input)) { Vquit_flag = Vthrow_on_input; /* If we're inside a function that wants immediate quits, do it now. */ if (immediate_quit && NILP (Vinhibit_quit)) { immediate_quit = 0; QUIT; } } } This call to QUIT is the problem, because this code runs in a different thread than the main Lisp thread, the one that set up the setjmp point to which we longjmp when we throw to top level. So it unwinds the wrong stack. By contrast, C-g does not call signal_user_input to be called, see above. So it avoids this fate.