GNU bug report logs - #9087
Crash reading from minibuffer with icomplete-mode

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, jasonr <at> gnu.org
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 <at> gmx.at>
> CC: monnier <at> iro.umontreal.ca, jasonr <at> gnu.org, claudio.bley <at> gmail.com, 
>  lekktu <at> gmail.com, 9087 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.