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: Claudio Bley
Subject: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sun, 01 Jan 2012 21:56:11 +0100
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.8 Emacs/23.3 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

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@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







reply via email to

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