Subject: bug#9087: closed (Re: bug#9087: Crash reading from minibuffer with icomplete-mode)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 14 Jan 2012 20:19:02 +0000

Your bug report

#9087: Crash reading from minibuffer with icomplete-mode

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
9087: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9087
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
From: Eli Zaretskii <[email-masked]>
To: Stefan Monnier <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sat, 14 Jan 2012 22:16:49 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Stefan Monnier <[email-masked]>
> Cc: Jason Rumney <[email-masked]>,  [email-masked],  [email-masked],  [email-masked],  [email-masked]
> 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.

Subject: Crash reading from minibuffer with icomplete-mode
From: Juanma Barranquero <[email-masked]>
To: Bug-Gnu-Emacs <[email-masked]>
Date: Fri, 15 Jul 2011 00:54:00 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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.