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

Previous Next

Full log

Message #140 received at 9087 <at> debbugs.gnu.org (full text, mbox):

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
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 12:58:34 +0200

> Date: Sat, 07 Jan 2012 11:10:48 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
>  > I can avoid the crash with the patch below.  But it defers the
>  > throwing until Emacs is done whatever it was doing (in this case,
>  > evaluating byte code).  Is this acceptable?  If not, what can we do to
>  > make the throwing more "immediate"?
> 
> Could you shortly explain the possible consequences of applying this
> patch

1. The crash is avoided. ;-)
2. The Emacs reaction to input event under throw-on-input is delayed
   until Emacs actually tries to read input.

(It is possible that 2. is actually what needs to happen in this case;
I don't know because the exact effects of throw-on-input are not
documented anywhere I could find.)

> and why the crash doesn't happen in non-compiled code

To trigger the crash, immediate_quit should be non-zero, because only
then would signal_user_input do a QUIT.  immediate_quit is set
non-zero by `nth' only when we run byte code that calls it (see
bytecode.c around line 1007); the function Fnth, called by
non-compiled Lisp code, does not do that.

The choice of `nth' is just one possibility to trigger this; you can
do it in any code that calls some primitive which sets immediate_quit
non-zero.

Previous Next

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