--- Begin Message ---
|
Subject: |
Crash reading from minibuffer with icomplete-mode |
|
Date: |
Fri, 15 Jul 2011 00:54:00 +0200 |
The backtraces below are from today's trunk, but I can also reproduce
the bug with the emacs-23 branch (Windows build in both cases).
This is sort of a recipe for the bug:
- Start emacs with "emacs -Q -f icomplete-mode".
- Run M-x set-face-font and set a font for a face; in my examples, I
try to set font-lock-comment-face.
- Choose a font, for example I set
-outline-Consolas-bold-normal-normal-mono-13-*-*-*-c-*-iso10646-1
- Then run again "M-x set-face-font <RET> M-p <RET> M-p", to select
the same face and the same font, and then modify the completion for
the face. In my tests, I go to the family name "Consolas", remove it
with M-d and start fiddling with completions of "Droid Sans Mono"
(which I have installed), typing for example just "Droid S" <TAB>,
then <M-backspace>, etc. Sooner or later it crashes every time.
Crashes are not always identical, but all of them happen in a call to
`byte-code' from inside `icomplete-exhibit'. After the signature there
are two examples.
I can repeat the crash easily, so if no one can reproduce it, pointers
to debugging this are welcome.
Juanma
=== Backtrace from trunk (1) ===
gdb: unknown target exception 0xc0000029 at 0x77be07b6
Program received signal ?, Unknown signal.
[Switching to Thread 5784.0x14c4]
0x77be07b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
(gdb) bt
#0 0x77be07b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
#1 0x0088da00 in ?? ()
#2 0x771e07f0 in setjmp () from C:\Windows\syswow64\msvcrt.dll
#3 0x0088ffc4 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Lisp Backtrace:
"byte-code" (0x889200)
"window-size-fixed-1" (0x8895a4)
"byte-code" (0x889770)
"window-size-fixed-1" (0x889b14)
"window-size-fixed-p" (0x889d74)
"window-sizable" (0x889fd4)
"window--resize-root-window-vertically" (0x88a244)
"byte-code" (0x88dc50)
"icomplete-exhibit" (0x88e0c8)
"run-hooks" (0x88e174)
0x35feba0 PVEC_COMPILED
"read-from-minibuffer" (0x88ea5c)
"completing-read-default" (0x88ecc4)
"completing-read" (0x88edd4)
"read-face-font" (0x88f034)
"read-face-and-attribute" (0x88f1f0)
"call-interactively" (0x88f644)
"execute-extended-command" (0x88f884)
"call-interactively" (0x88fb24)
=== Backtrace from trunk (2) ===
gdb: unknown target exception 0xc0000029 at 0x77be07b6
Program received signal ?, Unknown signal.
[Switching to Thread 4812.0x15ac]
0x77be07b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
(gdb) bt
#0 0x77be07b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
#1 0x0088da00 in ?? ()
#2 0x771e07f0 in setjmp () from C:\Windows\syswow64\msvcrt.dll
#3 0x0088ffc4 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Lisp Backtrace:
"byte-code" (0x88dc50)
"icomplete-exhibit" (0x88e0c8)
"run-hooks" (0x88e174)
0x35feba0 PVEC_COMPILED
"read-from-minibuffer" (0x88ea5c)
"completing-read-default" (0x88ecc4)
"completing-read" (0x88edd4)
"read-face-font" (0x88f034)
"read-face-and-attribute" (0x88f1f0)
"call-interactively" (0x88f644)
"execute-extended-command" (0x88f884)
"call-interactively" (0x88fb24)
=== Backtrace from emacs-23 ===
gdb: unknown target exception 0xc0000029 at 0x77be07b6
Program received signal ?, Unknown signal.
[Switching to Thread 5976.0xf64]
0x77be07b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
(gdb) bt
#0 0x77be07b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
#1 0x0088dcc0 in ?? ()
#2 0x771e07f0 in setjmp () from C:\Windows\syswow64\msvcrt.dll
#3 0x0088ffc4 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Lisp Backtrace:
"byte-code" (0x88def0)
"icomplete-exhibit" (0x88e348)
"run-hooks" (0x88e3f4)
0x2fa6ae0 There is no member named size.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#9087: Crash reading from minibuffer with icomplete-mode |
|
Date: |
Sat, 14 Jan 2012 22:16:49 +0200 |
> From: Stefan Monnier <address@hidden>
> Cc: Jason Rumney <address@hidden>, address@hidden, address@hidden,
> address@hidden, address@hidden
> Date: Sat, 07 Jan 2012 13:21:39 -0500
>
> >> > 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?
> >> Is a C-g also delayed in a similar way under w32?
> > Yes, it is, at least in this case.
>
> Then it's perfectly OK to delay the throw-on-input.
Thanks. I committed the changes and am closing the bug.
--- End Message ---