From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: claudio.bley@gmail.com, lekktu@gmail.com, 9087@debbugs.gnu.org
Subject: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 16:59:18 +0200 [thread overview]
Message-ID: <83lipjftix.fsf@gnu.org> (raw)
In-Reply-To: <4F084F4B.8040700@gmx.at>
> Date: Sat, 07 Jan 2012 14:57:31 +0100
> From: martin rudalics <rudalics@gmx.at>
> 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.
next prev parent reply other threads:[~2012-01-07 14:59 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-14 22:54 bug#9087: Crash reading from minibuffer with icomplete-mode Juanma Barranquero
2011-07-15 7:30 ` martin rudalics
2011-07-15 12:12 ` Juanma Barranquero
2011-07-15 12:23 ` martin rudalics
2011-07-15 16:40 ` Juanma Barranquero
2011-07-15 11:13 ` Eli Zaretskii
2011-07-15 12:11 ` Juanma Barranquero
2011-07-15 12:15 ` Juanma Barranquero
2011-07-15 12:29 ` Eli Zaretskii
2011-07-15 15:12 ` Juanma Barranquero
2011-07-15 15:24 ` Eli Zaretskii
2011-07-15 16:39 ` Juanma Barranquero
2011-07-15 17:12 ` Eli Zaretskii
2011-07-16 23:19 ` Juanma Barranquero
2011-07-17 3:08 ` Eli Zaretskii
2011-07-18 2:07 ` Juanma Barranquero
2011-07-18 3:01 ` Eli Zaretskii
2011-07-18 11:53 ` Juanma Barranquero
2011-07-18 16:45 ` Eli Zaretskii
2011-07-18 17:34 ` Juanma Barranquero
2011-07-17 9:38 ` martin rudalics
2011-07-18 1:59 ` Juanma Barranquero
2011-08-14 20:13 ` Chong Yidong
2011-09-14 14:43 ` Juanma Barranquero
2012-01-01 20:56 ` Claudio Bley
2012-01-01 21:24 ` Juanma Barranquero
2012-01-01 21:43 ` Eli Zaretskii
2012-01-02 16:16 ` Claudio Bley
2012-01-04 15:44 ` Claudio Bley
2012-01-06 10:02 ` Eli Zaretskii
2012-01-06 12:48 ` Juanma Barranquero
2012-01-06 13:19 ` martin rudalics
2012-01-06 13:26 ` Juanma Barranquero
2012-01-06 15:17 ` Eli Zaretskii
2012-01-06 16:07 ` martin rudalics
2012-01-06 19:01 ` Eli Zaretskii
2012-01-06 19:45 ` martin rudalics
2012-01-06 19:53 ` Eli Zaretskii
2012-01-06 20:50 ` Eli Zaretskii
2012-01-06 22:34 ` Juanma Barranquero
2012-01-07 0:42 ` Stefan Monnier
2012-01-07 8:31 ` Eli Zaretskii
2012-01-07 10:11 ` martin rudalics
2012-01-07 10:49 ` Eli Zaretskii
2012-01-07 11:51 ` martin rudalics
2012-01-07 12:21 ` Eli Zaretskii
2012-01-07 13:57 ` martin rudalics
2012-01-07 14:59 ` Eli Zaretskii [this message]
2012-01-07 16:27 ` martin rudalics
2012-01-07 17:05 ` Eli Zaretskii
2012-01-07 17:17 ` martin rudalics
2012-01-07 17:31 ` Eli Zaretskii
2012-01-07 17:45 ` martin rudalics
2012-01-07 17:52 ` Eli Zaretskii
2012-01-07 13:12 ` Andreas Schwab
2012-01-07 13:57 ` martin rudalics
2012-01-07 15:00 ` Eli Zaretskii
2012-01-07 18:21 ` Stefan Monnier
2012-01-07 18:59 ` Eli Zaretskii
2012-01-08 14:01 ` Stefan Monnier
2012-01-14 20:16 ` Eli Zaretskii
2012-01-07 10:10 ` martin rudalics
2012-01-07 10:58 ` Eli Zaretskii
2012-01-07 11:52 ` martin rudalics
2012-01-07 12:11 ` Eli Zaretskii
2012-01-07 13:55 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83lipjftix.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=9087@debbugs.gnu.org \
--cc=claudio.bley@gmail.com \
--cc=lekktu@gmail.com \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.