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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Juanma Barranquero <lekktu <at> gmail.com>
Subject: bug#9087: closed (Re: bug#9087: Crash reading from minibuffer
 with icomplete-mode)
Date: Sat, 14 Jan 2012 20:19:02 +0000

[Message part 1 (text/plain, inline)]

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 9087 <at> debbugs.gnu.org.

-- 
9087: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9087
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: claudio.bley <at> gmail.com, rudalics <at> gmx.at, lekktu <at> gmail.com,
	9087-done <at> debbugs.gnu.org, jasonr <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 14 Jan 2012 22:16:49 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Jason Rumney <jasonr <at> gnu.org>,  rudalics <at> gmx.at,  claudio.bley <at> gmail.com,  lekktu <at> gmail.com,  9087 <at> debbugs.gnu.org
> 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.

[Message part 3 (message/rfc822, inline)]

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
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.

Previous Next

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