|
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
[Prev in Thread] | Current Thread | [Next in Thread] |