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

Previous Next

Full log

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

From: claudio.bley <at> gmail.com (Claudio Bley)
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sun, 01 Jan 2012 21:56:11 +0100

Hi.

I'm using ido-mode and this kind of crash is bugging me almost every
single day when using the ido-find-file (C-x C-f) function.

Here's an /illuminating/ backtrace I've captured with WinDbg the other
day:

Note: most recent calls last

- thread 0

... (some calls omitted)

Ffuncall at C:\src\unix\emacs-trunk\src/eval.c:3023
funcall_lambda at C:\src\unix\emacs-trunk\src/eval.c:3205
exec_byte_code at C:\src\unix\emacs-trunk\src/bytecode.c:785
Ffuncall at C:\src\unix\emacs-trunk\src/eval.c:3023
funcall_lambda at C:\src\unix\emacs-trunk\src/eval.c:3205
exec_byte_code at C:\src\unix\emacs-trunk\src/bytecode.c:785
Ffuncall at C:\src\unix\emacs-trunk\src/eval.c:2977
Fmapc at C:\src\unix\emacs-trunk\src/fns.c:2436
mapcar1 at C:\src\unix\emacs-trunk\src/fns.c:2346
call1 at C:\src\unix\emacs-trunk\src/eval.c:2743
Ffuncall at C:\src\unix\emacs-trunk\src/eval.c:3023
funcall_lambda at C:\src\unix\emacs-trunk\src/eval.c:3205
exec_byte_code at C:\src\unix\emacs-trunk\src/bytecode.c:1837
w32_abort at C:\src\unix\emacs-trunk\src/w32fns.c:7191

- thread 2

w32_msg_worker <at> 4 at C:\src\unix\emacs-trunk\src/w32fns.c:2472
w32_msg_pump at C:\src\unix\emacs-trunk\src/w32fns.c:2346
w32_wnd_proc at C:\src\unix\emacs-trunk\src/w32fns.c:2920
post_character_message at C:\src\unix\emacs-trunk\src/w32fns.c:2550
signal_user_input at C:\src\unix\emacs-trunk\src/w32fns.c:2487
Fthrow at C:\src\unix\emacs-trunk\src/eval.c:1334
Fthrow at C:\src\unix\emacs-trunk\src/eval.c:1330

- thread 3

reader_thread at C:\src\unix\emacs-trunk\src/w32proc.c:253
_sys_wait_accept at C:\src\unix\emacs-trunk\src/w32.c:5369

----------------------------------------------------------------------

In summary:

Thread 0 (the lisp thread) is currently evaluating some byte code.

Thread 2 (the win32 messaging thread) receives a key press and because
the Vthrow_on_input flag is set, decides to do a QUIT; regardlessly
unwinding the stack of the currently running interpreter from another
thread!!!

Thread 0 is about to abort execution because it sensed that somehow
the binding stack has been corrupted.


Happy new year! :-)

- Claudio

Previous Next

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