bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9087: Crash reading from minibuffer with icomplete-mode


From: Eli Zaretskii
Subject: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 19:05:41 +0200

> Date: Sat, 07 Jan 2012 17:27:45 +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
> 
>  > 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.
> 
> Thanks.  I'm beginning to understand.  Is post_character_message the
> only potential source of this problem or are there others as well?

There are others.  Search for the callers of signal_user_input, and
you will find them.  E.g., it is called for mouse inputs as well.

>  > By contrast, C-g does not call signal_user_input to be called, see
>  > above.  So it avoids this fate.
> 
> Naively asked: Could we avoid the problem if on normal input we did not
> call signal_user_input but did something similar to C-g handling?

We could, but why would we want to?  signal_user_input does TRT,
except when immediate_quit is set.  If we don't call it, we won't be
able to support throw-on-input and while-no-input.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]