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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9087 in the body.
You can then email your comments to 9087 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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.

Message #8 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 09:30:29 +0200

> I can repeat the crash easily, so if no one can reproduce it, pointers
> to debugging this are welcome.

> "byte-code" (0x88dc50)
> "icomplete-exhibit" (0x88e0c8)
[...]
> "byte-code" (0x88dc50)
> "icomplete-exhibit" (0x88e0c8)

Does it get more meaningful when you evaluate `icomplete-exhibit' before
running the code?

martin

Message #11 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 14:13:39 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 15 Jul 2011 00:54:00 +0200
> 
> === 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?)

Try "thread apply all bt", perhaps that will give a more meaningful
backtrace in one of the other threads.

Message #14 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 14:11:22 +0200

On Fri, Jul 15, 2011 at 13:13, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Try "thread apply all bt", perhaps that will give a more meaningful
> backtrace in one of the other threads.

Unexpectedly, I had a much more informative backtrace:

Breakpoint 1, w32_abort () at w32fns.c:7182
7182      button = MessageBox (NULL,
(gdb) bt
#0  w32_abort () at w32fns.c:7182
#1  0x0103a942 in xfree (block=0x32d4f80) at alloc.c:713
#2  0x01004b8d in pop_kboard () at keyboard.c:923
#3  0x01004c6a in restore_kboard_configuration (was_locked=53151794)
at keyboard.c:985
#4  0x01039a41 in unbind_to (count=34, value=53151770) at eval.c:3437
#5  0x010334d9 in unwind_to_catch (catch=0x88d9f0, value=53151794) at
eval.c:1290
#6  0x01033577 in Fthrow (tag=55370426, value=53151794) at eval.c:1328
#7  0x0114eb0c in re_match_2_internal (bufp=0x1637588, string1=0x0, size1=0,
    string2=0x4e1d190
"-outline-Gabriola-normal-normal-normal-decorative-*-*-*-*-p-*-iso8859-7",
size2=71, pos=0, regs=0x1638de8, stop=71)
    at regex.c:6280
#8  0x01144622 in re_search_2 (bufp=0x1637588, str1=0x0, size1=0,
    str2=0x4e1d190
"-outline-Gabriola-normal-normal-normal-decorative-*-*-*-*-p-*-iso8859-7",
size2=71, startpos=0, range=0, regs=0x1638de8,
    stop=71) at regex.c:4514
#9  0x01143525 in re_search (bufp=0x1637588, string=0x4e1d190
"-outline-Gabriola-normal-normal-normal-decorative-*-*-*-*-p-*-iso8859-7",
size=71,
    startpos=0, range=71, regs=0x1638de8) at regex.c:4295
#10 0x010f9ba3 in string_match_1 (regexp=82715057, string=55242833,
start=0, posix=0) at search.c:411
#11 0x010f9cdc in Fstring_match (regexp=82715057, string=55242833,
start=0) at search.c:451
#12 0x011088fd in Fall_completions (string=20058337,
collection=57786174, predicate=53151770, hide_spaces=53151770) at
minibuf.c:1590
#13 0x01037e6b in Ffuncall (nargs=4, args=0x88ba84) at eval.c:3020
#14 0x01124959 in exec_byte_code (bytestr=20580337, vector=20580405,
maxdepth=48, args_template=4112, nargs=4, args=0x88bcf8) at
bytecode.c:785
#15 0x010387f8 in funcall_lambda (fun=20580309, nargs=4,
arg_vector=0x88bce8) at eval.c:3174
#16 0x01038113 in Ffuncall (nargs=5, args=0x88bce4) at eval.c:3058
#17 0x01124959 in exec_byte_code (bytestr=20581233, vector=55482565,
maxdepth=24, args_template=0, nargs=0, args=0x88bf54) at
bytecode.c:785
#18 0x010387f8 in funcall_lambda (fun=55481381, nargs=0,
arg_vector=0x88bf54) at eval.c:3174
#19 0x01038113 in Ffuncall (nargs=1, args=0x88bf50) at eval.c:3058
#20 0x01035bd9 in eval_sub (form=55790686) at eval.c:2329
#21 0x0103395a in internal_lisp_condition_case (var=54494738,
bodyform=55790686, handlers=55790638) at eval.c:1440
#22 0x01125214 in exec_byte_code (bytestr=20580897, vector=20581077,
maxdepth=144, args_template=5136, nargs=4, args=0x88c434) at
bytecode.c:981
#23 0x010387f8 in funcall_lambda (fun=20580869, nargs=4,
arg_vector=0x88c424) at eval.c:3174
#24 0x01038113 in Ffuncall (nargs=5, args=0x88c420) at eval.c:3058
#25 0x01124959 in exec_byte_code (bytestr=20581345, vector=20581397,
maxdepth=56, args_template=4112, nargs=4, args=0x88c6a8) at
bytecode.c:785
#26 0x010387f8 in funcall_lambda (fun=20581317, nargs=4,
arg_vector=0x88c698) at eval.c:3174
#27 0x01038113 in Ffuncall (nargs=5, args=0x88c694) at eval.c:3058
#28 0x01124959 in exec_byte_code (bytestr=20565313, vector=56501637,
maxdepth=24, args_template=1028, nargs=1, args=0x88c8fc) at
bytecode.c:785
#29 0x010387f8 in funcall_lambda (fun=56501221, nargs=1,
arg_vector=0x88c8f8) at eval.c:3174
#30 0x01038113 in Ffuncall (nargs=2, args=0x88c8f4) at eval.c:3058
#31 0x01124959 in exec_byte_code (bytestr=20560633, vector=54625861,
maxdepth=20, args_template=0, nargs=0, args=0x88cb64) at
bytecode.c:785
#32 0x010387f8 in funcall_lambda (fun=54628197, nargs=0,
arg_vector=0x88cb64) at eval.c:3174
#33 0x01038113 in Ffuncall (nargs=1, args=0x88cb60) at eval.c:3058
#34 0x01035bd9 in eval_sub (form=55791190) at eval.c:2329
#35 0x0103395a in internal_lisp_condition_case (var=54638482,
bodyform=55791190, handlers=55791142) at eval.c:1440
#36 0x01125214 in exec_byte_code (bytestr=20560457, vector=20560557,
maxdepth=60, args_template=2056, nargs=2, args=0x88cff0) at
bytecode.c:981
#37 0x010387f8 in funcall_lambda (fun=20560429, nargs=2,
arg_vector=0x88cfe8) at eval.c:3174
#38 0x01038113 in Ffuncall (nargs=3, args=0x88cfe4) at eval.c:3058
#39 0x01124959 in exec_byte_code (bytestr=20564961, vector=20565261,
maxdepth=60, args_template=5136, nargs=5, args=0x88d278) at
bytecode.c:785
#40 0x010387f8 in funcall_lambda (fun=20565173, nargs=5,
arg_vector=0x88d264) at eval.c:3174
#41 0x01038113 in Ffuncall (nargs=6, args=0x88d260) at eval.c:3058
#42 0x01124959 in exec_byte_code (bytestr=20567217, vector=20567365,
maxdepth=72, args_template=0, nargs=0, args=0x88d4e4) at
bytecode.c:785
#43 0x010387f8 in funcall_lambda (fun=20567189, nargs=0,
arg_vector=0x88d4e4) at eval.c:3174
#44 0x01038113 in Ffuncall (nargs=1, args=0x88d4e0) at eval.c:3058
#45 0x01124959 in exec_byte_code (bytestr=55203873, vector=56207365,
maxdepth=36, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#46 0x01038c78 in funcall_lambda (fun=56616997, nargs=4,
arg_vector=0x88d754) at eval.c:3240
#47 0x01038113 in Ffuncall (nargs=5, args=0x88d750) at eval.c:3058
#48 0x01124959 in exec_byte_code (bytestr=55220513, vector=56115845,
maxdepth=20, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#49 0x01123f0a in Fbyte_code (bytestr=55220513, vector=56115845,
maxdepth=20) at bytecode.c:423
#50 0x01035e98 in eval_sub (form=54813086) at eval.c:2363
#51 0x01033424 in internal_catch (tag=55370426, func=0x103547a
<eval_sub>, arg=54813086) at eval.c:1247
#52 0x011251ad in exec_byte_code (bytestr=55220593, vector=56617093,
maxdepth=8, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:966
#53 0x01123f0a in Fbyte_code (bytestr=55220593, vector=56617093,
maxdepth=8) at bytecode.c:423
#54 0x01035e98 in eval_sub (form=54813166) at eval.c:2363
#55 0x0103395a in internal_lisp_condition_case (var=53151770,
bodyform=54813166, handlers=54813054) at eval.c:1440
#56 0x01125214 in exec_byte_code (bytestr=55220817, vector=55929221,
maxdepth=28, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:981
#57 0x01038c78 in funcall_lambda (fun=56617189, nargs=0,
arg_vector=0x88e0c8) at eval.c:3240
#58 0x01038113 in Ffuncall (nargs=1, args=0x88e0c4) at eval.c:3058
#59 0x01036c72 in funcall_nil (nargs=1, args=0x88e0c4) at eval.c:2526
#60 0x010370db in run_hook_with_args (nargs=1, args=0x88e0c4,
funcall=0x1036c5a <funcall_nil>) at eval.c:2715
#61 0x01036cbc in Frun_hooks (nargs=1, args=0x88e174) at eval.c:2553
#62 0x01037a78 in Ffuncall (nargs=2, args=0x88e170) at eval.c:2991
#63 0x01124959 in exec_byte_code (bytestr=55221073, vector=53285573,
maxdepth=8, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#64 0x01038c78 in funcall_lambda (fun=56617893, nargs=0,
arg_vector=0x88e3f4) at eval.c:3240
#65 0x01038113 in Ffuncall (nargs=1, args=0x88e3f0) at eval.c:3058
#66 0x010371d9 in call0 (fn=56617893) at eval.c:2763
#67 0x0100772d in safe_run_hooks_1 () at keyboard.c:1868
#68 0x01033a64 in internal_condition_case (bfun=0x10076b0
<safe_run_hooks_1>, handlers=53151794, hfun=0x100772f
<safe_run_hooks_error>)
    at eval.c:1493
#69 0x01007b5b in safe_run_hook_funcall (nargs=1, args=0x88e590) at
keyboard.c:1923
#70 0x010370db in run_hook_with_args (nargs=1, args=0x88e590,
funcall=0x1007aa1 <safe_run_hook_funcall>) at eval.c:2715
#71 0x01007baa in safe_run_hooks (hook=56617893) at keyboard.c:1940
#72 0x01006461 in command_loop_1 () at keyboard.c:1586
#73 0x01033a64 in internal_condition_case (bfun=0x100545f
<command_loop_1>, handlers=53209522, hfun=0x1004c89 <cmd_error>) at
eval.c:1493
#74 0x010050c5 in command_loop_2 (ignore=53151770) at keyboard.c:1156
#75 0x01033424 in internal_catch (tag=53301730, func=0x10050a2
<command_loop_2>, arg=53151770) at eval.c:1247
#76 0x0100502c in command_loop () at keyboard.c:1121
#77 0x01004647 in recursive_edit_1 () at keyboard.c:756
#78 0x011059d7 in read_minibuf (map=53496798, initial=53151770,
prompt=56021441, backup_n=53151770, expflag=0, histvar=53327474,
histpos=0,
    defalt=53151770, allow_props=0, inherit_input_method=0) at minibuf.c:663
#79 0x0110672a in Fread_from_minibuffer (prompt=56021441,
initial_contents=53151770, keymap=53496798, sys_read=53151770,
hist=53151770,
    default_value=53151770, inherit_input_method=53151770) at minibuf.c:957
#80 0x01038024 in Ffuncall (nargs=8, args=0x88ea58) at eval.c:3035
#81 0x01124959 in exec_byte_code (bytestr=20583305, vector=20583389,
maxdepth=72, args_template=8200, nargs=8, args=0x88ece4) at
bytecode.c:785
#82 0x010387f8 in funcall_lambda (fun=20583277, nargs=8,
arg_vector=0x88ecc4) at eval.c:3174
#83 0x01038113 in Ffuncall (nargs=9, args=0x88ecc0) at eval.c:3058
#84 0x01108b01 in Fcompleting_read (prompt=56021441,
collection=57786174, predicate=53151770, require_match=53151770,
initial_input=53151770,
    hist=53151770, def=53151770, inherit_input_method=53151770) at
minibuf.c:1702
#85 0x010380cb in Ffuncall (nargs=3, args=0x88edd0) at eval.c:3042
#86 0x01124959 in exec_byte_code (bytestr=20387729, vector=20387805,
maxdepth=32, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#87 0x01038c78 in funcall_lambda (fun=20387701, nargs=2,
arg_vector=0x88f034) at eval.c:3240
#88 0x01038113 in Ffuncall (nargs=3, args=0x88f030) at eval.c:3058
#89 0x01124959 in exec_byte_code (bytestr=20388425, vector=20388517,
maxdepth=16, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#90 0x01038c78 in funcall_lambda (fun=20388397, nargs=1,
arg_vector=0x88f1f0) at eval.c:3240
#91 0x01038448 in apply_lambda (fun=20388397, args=20382790) at eval.c:3117
#92 0x010361ba in eval_sub (form=20382782) at eval.c:2402
#93 0x01035469 in Feval (form=20382782, lexical=53151770) at eval.c:2211
#94 0x01121b49 in Fcall_interactively (function=54369026,
record_flag=53151794, keys=53172997) at callint.c:346
#95 0x01037dec in Ffuncall (nargs=4, args=0x88f640) at eval.c:3016
#96 0x01037287 in call3 (fn=53316994, arg1=54369026, arg2=53151794,
arg3=53151770) at eval.c:2809
#97 0x0101ffc1 in Fcommand_execute (cmd=54369026,
record_flag=53151794, keys=53151770, special=53151770) at
keyboard.c:10274
#98 0x010202bd in Fexecute_extended_command (prefixarg=53151770) at
keyboard.c:10363
#99 0x01037d0c in Ffuncall (nargs=2, args=0x88f880) at eval.c:3009
#100 0x01123986 in Fcall_interactively (function=53207762,
record_flag=53151770, keys=53172997) at callint.c:857
#101 0x01037dec in Ffuncall (nargs=4, args=0x88fb20) at eval.c:3016
#102 0x01037287 in call3 (fn=53316994, arg1=53207762, arg2=53151770,
arg3=53151770) at eval.c:2809
#103 0x0101ffc1 in Fcommand_execute (cmd=53207762,
record_flag=53151770, keys=53151770, special=53151770) at
keyboard.c:10274
#104 0x01006422 in command_loop_1 () at keyboard.c:1572
#105 0x01033a64 in internal_condition_case (bfun=0x100545f
<command_loop_1>, handlers=53209522, hfun=0x1004c89 <cmd_error>) at
eval.c:1493
#106 0x010050c5 in command_loop_2 (ignore=53151770) at keyboard.c:1156
#107 0x01033424 in internal_catch (tag=53207546, func=0x10050a2
<command_loop_2>, arg=53151770) at eval.c:1247
#108 0x0100507d in command_loop () at keyboard.c:1135
#109 0x01004647 in recursive_edit_1 () at keyboard.c:756
#110 0x01004969 in Frecursive_edit () at keyboard.c:820
#111 0x010027eb in main (argc=4, argv=0xa52d70) at emacs.c:1701

Lisp Backtrace:
"all-completions" (0x88ba88)
"completion-pcm--all-completions" (0x88bce8)
0x34e9420 PVEC_COMPILED
"funcall" (0x88bf50)
"completion-pcm--find-all-completions" (0x88c424)
"completion-pcm-all-completions" (0x88c698)
0x35e23e0 PVEC_COMPILED
0x3418f60 PVEC_COMPILED
"funcall" (0x88cb60)
"completion--some" (0x88cfe8)
"completion-all-completions" (0x88d264)
"completion-all-sorted-completions" (0x88d4e4)
"icomplete-completions" (0x88d754)
"byte-code" (0x88d930)
"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)
(gdb)


The result of "thread apply all bt" is more or less the same:

(gdb) thread apply all bt

Thread 6 (Thread 4236.0x11c8):
#0  0x774d1f36 in ntdll!LdrQueryProcessModuleInformation () from
C:\Windows\system32\ntdll.dll
#1  0x774d1f36 in ntdll!LdrQueryProcessModuleInformation () from
C:\Windows\system32\ntdll.dll
#2  0x774f471e in ntdll!TpCallbackMayRunLong () from
C:\Windows\system32\ntdll.dll
#3  0x00000130 in ?? ()
#4  0x79f4fedc in ?? ()
#5  0x765b339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from
C:\Windows\syswow64\kernel32.dll
#6  0x00d22e80 in ?? ()
#7  0x774e9ed2 in wcscat () from C:\Windows\system32\ntdll.dll
#8  0x00d22e80 in ?? ()
#9  0x774e9ea5 in wcscat () from C:\Windows\system32\ntdll.dll
#10 0x774f6679 in ntdll!RtlpQueryDefaultUILanguage () from
C:\Windows\system32\ntdll.dll
#11 0x00d22e80 in ?? ()
#12 0x00000000 in ?? ()

Lisp Backtrace:
"all-completions" (0x88ba88)
"completion-pcm--all-completions" (0x88bce8)
0x34e9420 PVEC_COMPILED
"funcall" (0x88bf50)
"completion-pcm--find-all-completions" (0x88c424)
"completion-pcm-all-completions" (0x88c698)
0x35e23e0 PVEC_COMPILED
0x3418f60 PVEC_COMPILED
"funcall" (0x88cb60)
"completion--some" (0x88cfe8)
"completion-all-completions" (0x88d264)
"completion-all-sorted-completions" (0x88d4e4)
"icomplete-completions" (0x88d754)
"byte-code" (0x88d930)
"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)

Thread 5 (Thread 4236.0x133c):
#0  0x774d1f36 in ntdll!LdrQueryProcessModuleInformation () from
C:\Windows\system32\ntdll.dll
#1  0x774d1f36 in ntdll!LdrQueryProcessModuleInformation () from
C:\Windows\system32\ntdll.dll
#2  0x774f471e in ntdll!TpCallbackMayRunLong () from
C:\Windows\system32\ntdll.dll
#3  0x00000130 in ?? ()
#4  0x7974fedc in ?? ()
#5  0x765b339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from
C:\Windows\syswow64\kernel32.dll
#6  0x00d22e80 in ?? ()
#7  0x774e9ed2 in wcscat () from C:\Windows\system32\ntdll.dll
#8  0x00d22e80 in ?? ()
#9  0x774e9ea5 in wcscat () from C:\Windows\system32\ntdll.dll
#10 0x774f6679 in ntdll!RtlpQueryDefaultUILanguage () from
C:\Windows\system32\ntdll.dll
#11 0x00d22e80 in ?? ()
#12 0x00000000 in ?? ()

Lisp Backtrace:
"all-completions" (0x88ba88)
"completion-pcm--all-completions" (0x88bce8)
0x34e9420 PVEC_COMPILED
"funcall" (0x88bf50)
"completion-pcm--find-all-completions" (0x88c424)
"completion-pcm-all-completions" (0x88c698)
0x35e23e0 PVEC_COMPILED
0x3418f60 PVEC_COMPILED
"funcall" (0x88cb60)
"completion--some" (0x88cfe8)
"completion-all-completions" (0x88d264)
"completion-all-sorted-completions" (0x88d4e4)
"icomplete-completions" (0x88d754)
"byte-code" (0x88d930)
"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)

Thread 4 (Thread 4236.0x1330):
#0  0x774d1f36 in ntdll!LdrQueryProcessModuleInformation () from
C:\Windows\system32\ntdll.dll
#1  0x774d1f36 in ntdll!LdrQueryProcessModuleInformation () from
C:\Windows\system32\ntdll.dll
#2  0x774f471e in ntdll!TpCallbackMayRunLong () from
C:\Windows\system32\ntdll.dll
#3  0x00000158 in ?? ()
#4  0x78f4fedc in ?? ()
#5  0x765b339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from
C:\Windows\syswow64\kernel32.dll
#6  0x00d23ec0 in ?? ()
#7  0x774e9ed2 in wcscat () from C:\Windows\system32\ntdll.dll
#8  0x00d23ec0 in ?? ()
#9  0x774e9ea5 in wcscat () from C:\Windows\system32\ntdll.dll
#10 0x774f6679 in ntdll!RtlpQueryDefaultUILanguage () from
C:\Windows\system32\ntdll.dll
#11 0x00d23ec0 in ?? ()
#12 0x00000000 in ?? ()

Lisp Backtrace:
"all-completions" (0x88ba88)
"completion-pcm--all-completions" (0x88bce8)
0x34e9420 PVEC_COMPILED
"funcall" (0x88bf50)
"completion-pcm--find-all-completions" (0x88c424)
"completion-pcm-all-completions" (0x88c698)
0x35e23e0 PVEC_COMPILED
0x3418f60 PVEC_COMPILED
"funcall" (0x88cb60)
"completion--some" (0x88cfe8)
"completion-all-completions" (0x88d264)
"completion-all-sorted-completions" (0x88d4e4)
"icomplete-completions" (0x88d754)
"byte-code" (0x88d930)
"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)

Thread 3 (Thread 4236.0xf28):
#0  0x0122e48d in w32_abort () at w32fns.c:7182
#1  0x0103cab3 in Fcons (car=53209954, cdr=53151770) at alloc.c:2639
#2  0x0103400b in Fsignal (error_symbol=53209954, data=53151770) at eval.c:1745
#3  0x010340ed in xsignal (error_symbol=53209954, data=53151770) at eval.c:1769
#4  0x0103410c in xsignal0 (error_symbol=53209954) at eval.c:1778
#5  0x012621ca in text_read_only (propval=53151794) at textprop.c:92
#6  0x012699f0 in verify_interval_modification (buf=0x3591000,
start=1, end=132) at textprop.c:2157
#7  0x011121f3 in prepare_to_modify_buffer (start=1, end=132,
preserve_ptr=0x7481f83c) at insdel.c:1851
#8  0x011117c1 in del_range_1 (from=1, to=132, prepare=1,
ret_string=0) at insdel.c:1601
#9  0x0111174a in del_range (from=1, to=132) at insdel.c:1576
#10 0x010bfc20 in Ferase_buffer () at buffer.c:1950
#11 0x011064c8 in read_minibuf_unwind (data=53151770) at minibuf.c:864
#12 0x01039a41 in unbind_to (count=27, value=53151770) at eval.c:3437
#13 0x010334d9 in unwind_to_catch (catch=0x88d9f0, value=53151794) at
eval.c:1290
#14 0x01033577 in Fthrow (tag=55370426, value=53151794) at eval.c:1328
#15 0x0122260d in signal_user_input () at w32fns.c:2482
#16 0x012226aa in post_character_message (hwnd=0x5204ea, msg=258,
wParam=109, lParam=3276801, modifiers=0) at w32fns.c:2542
#17 0x012236eb in w32_wnd_proc (hwnd=0x5204ea, msg=258, wParam=109,
lParam=3276801) at w32fns.c:2913
#18 0x767162fa in USER32!OffsetRect () from C:\Windows\syswow64\user32.dll
#19 0x005204ea in ?? ()
#20 0x00000102 in ?? ()
#21 0x0000006d in ?? ()
#22 0x00320001 in ?? ()
#23 0x012226d3 in post_character_message (hwnd=0x12226d3, msg=5375210,
wParam=258, lParam=109, modifiers=3276801) at w32fns.c:2546
#24 0x76716d3a in USER32!IsWindow () from C:\Windows\syswow64\user32.dll
#25 0x012226d3 in post_character_message (hwnd=0x0, msg=19015379,
wParam=5375210, lParam=258, modifiers=109) at w32fns.c:2546
#26 0x767177c4 in USER32!AnyPopup () from C:\Windows\syswow64\user32.dll
#27 0x00000000 in ?? ()

Lisp Backtrace:
"all-completions" (0x88ba88)
"completion-pcm--all-completions" (0x88bce8)
0x34e9420 PVEC_COMPILED
"funcall" (0x88bf50)
"completion-pcm--find-all-completions" (0x88c424)
"completion-pcm-all-completions" (0x88c698)
0x35e23e0 PVEC_COMPILED
0x3418f60 PVEC_COMPILED
"funcall" (0x88cb60)
"completion--some" (0x88cfe8)
"completion-all-completions" (0x88d264)
"completion-all-sorted-completions" (0x88d4e4)
"icomplete-completions" (0x88d754)
"byte-code" (0x88d930)
"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)

Thread 2 (Thread 4236.0x1280):
#0  0x774d014d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\Windows\system32\ntdll.dll
#1  0x774d014d in ntdll!RtlEnableEarlyCriticalSectionEventCreation ()
from C:\Windows\system32\ntdll.dll
#2  0x774f431f in ntdll!TpCallbackMayRunLong () from
C:\Windows\system32\ntdll.dll
#3  0x00000003 in ?? ()
#4  0x00d23ca8 in ?? ()
#5  0x765b339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from
C:\Windows\syswow64\kernel32.dll
#6  0x00000000 in ?? ()

Lisp Backtrace:
"all-completions" (0x88ba88)
"completion-pcm--all-completions" (0x88bce8)
0x34e9420 PVEC_COMPILED
"funcall" (0x88bf50)
"completion-pcm--find-all-completions" (0x88c424)
"completion-pcm-all-completions" (0x88c698)
0x35e23e0 PVEC_COMPILED
0x3418f60 PVEC_COMPILED
"funcall" (0x88cb60)
"completion--some" (0x88cfe8)
"completion-all-completions" (0x88d264)
"completion-all-sorted-completions" (0x88d4e4)
"icomplete-completions" (0x88d754)
"byte-code" (0x88d930)
"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)

Thread 1 (Thread 4236.0x1274):
#0  w32_abort () at w32fns.c:7182
#1  0x0103a942 in xfree (block=0x32d4f80) at alloc.c:713
#2  0x01004b8d in pop_kboard () at keyboard.c:923
#3  0x01004c6a in restore_kboard_configuration (was_locked=53151794)
at keyboard.c:985
#4  0x01039a41 in unbind_to (count=34, value=53151770) at eval.c:3437
#5  0x010334d9 in unwind_to_catch (catch=0x88d9f0, value=53151794) at
eval.c:1290
#6  0x01033577 in Fthrow (tag=55370426, value=53151794) at eval.c:1328
#7  0x0114eb0c in re_match_2_internal (bufp=0x1637588, string1=0x0, size1=0,
    string2=0x4e1d190
"-outline-Gabriola-normal-normal-normal-decorative-*-*-*-*-p-*-iso8859-7",
size2=71, pos=0, regs=0x1638de8, stop=71)
    at regex.c:6280
#8  0x01144622 in re_search_2 (bufp=0x1637588, str1=0x0, size1=0,
    str2=0x4e1d190
"-outline-Gabriola-normal-normal-normal-decorative-*-*-*-*-p-*-iso8859-7",
size2=71, startpos=0, range=0, regs=0x1638de8,
    stop=71) at regex.c:4514
#9  0x01143525 in re_search (bufp=0x1637588, string=0x4e1d190
"-outline-Gabriola-normal-normal-normal-decorative-*-*-*-*-p-*-iso8859-7",
size=71,
    startpos=0, range=71, regs=0x1638de8) at regex.c:4295
#10 0x010f9ba3 in string_match_1 (regexp=82715057, string=55242833,
start=0, posix=0) at search.c:411
#11 0x010f9cdc in Fstring_match (regexp=82715057, string=55242833,
start=0) at search.c:451
#12 0x011088fd in Fall_completions (string=20058337,
collection=57786174, predicate=53151770, hide_spaces=53151770) at
minibuf.c:1590
#13 0x01037e6b in Ffuncall (nargs=4, args=0x88ba84) at eval.c:3020
#14 0x01124959 in exec_byte_code (bytestr=20580337, vector=20580405,
maxdepth=48, args_template=4112, nargs=4, args=0x88bcf8) at
bytecode.c:785
#15 0x010387f8 in funcall_lambda (fun=20580309, nargs=4,
arg_vector=0x88bce8) at eval.c:3174
#16 0x01038113 in Ffuncall (nargs=5, args=0x88bce4) at eval.c:3058
#17 0x01124959 in exec_byte_code (bytestr=20581233, vector=55482565,
maxdepth=24, args_template=0, nargs=0, args=0x88bf54) at
bytecode.c:785
#18 0x010387f8 in funcall_lambda (fun=55481381, nargs=0,
arg_vector=0x88bf54) at eval.c:3174
#19 0x01038113 in Ffuncall (nargs=1, args=0x88bf50) at eval.c:3058
#20 0x01035bd9 in eval_sub (form=55790686) at eval.c:2329
#21 0x0103395a in internal_lisp_condition_case (var=54494738,
bodyform=55790686, handlers=55790638) at eval.c:1440
#22 0x01125214 in exec_byte_code (bytestr=20580897, vector=20581077,
maxdepth=144, args_template=5136, nargs=4, args=0x88c434) at
bytecode.c:981
#23 0x010387f8 in funcall_lambda (fun=20580869, nargs=4,
arg_vector=0x88c424) at eval.c:3174
#24 0x01038113 in Ffuncall (nargs=5, args=0x88c420) at eval.c:3058
#25 0x01124959 in exec_byte_code (bytestr=20581345, vector=20581397,
maxdepth=56, args_template=4112, nargs=4, args=0x88c6a8) at
bytecode.c:785
#26 0x010387f8 in funcall_lambda (fun=20581317, nargs=4,
arg_vector=0x88c698) at eval.c:3174
#27 0x01038113 in Ffuncall (nargs=5, args=0x88c694) at eval.c:3058
#28 0x01124959 in exec_byte_code (bytestr=20565313, vector=56501637,
maxdepth=24, args_template=1028, nargs=1, args=0x88c8fc) at
bytecode.c:785
#29 0x010387f8 in funcall_lambda (fun=56501221, nargs=1,
arg_vector=0x88c8f8) at eval.c:3174
#30 0x01038113 in Ffuncall (nargs=2, args=0x88c8f4) at eval.c:3058
#31 0x01124959 in exec_byte_code (bytestr=20560633, vector=54625861,
maxdepth=20, args_template=0, nargs=0, args=0x88cb64) at
bytecode.c:785
#32 0x010387f8 in funcall_lambda (fun=54628197, nargs=0,
arg_vector=0x88cb64) at eval.c:3174
#33 0x01038113 in Ffuncall (nargs=1, args=0x88cb60) at eval.c:3058
#34 0x01035bd9 in eval_sub (form=55791190) at eval.c:2329
#35 0x0103395a in internal_lisp_condition_case (var=54638482,
bodyform=55791190, handlers=55791142) at eval.c:1440
#36 0x01125214 in exec_byte_code (bytestr=20560457, vector=20560557,
maxdepth=60, args_template=2056, nargs=2, args=0x88cff0) at
bytecode.c:981
#37 0x010387f8 in funcall_lambda (fun=20560429, nargs=2,
arg_vector=0x88cfe8) at eval.c:3174
#38 0x01038113 in Ffuncall (nargs=3, args=0x88cfe4) at eval.c:3058
#39 0x01124959 in exec_byte_code (bytestr=20564961, vector=20565261,
maxdepth=60, args_template=5136, nargs=5, args=0x88d278) at
bytecode.c:785
#40 0x010387f8 in funcall_lambda (fun=20565173, nargs=5,
arg_vector=0x88d264) at eval.c:3174
#41 0x01038113 in Ffuncall (nargs=6, args=0x88d260) at eval.c:3058
#42 0x01124959 in exec_byte_code (bytestr=20567217, vector=20567365,
maxdepth=72, args_template=0, nargs=0, args=0x88d4e4) at
bytecode.c:785
#43 0x010387f8 in funcall_lambda (fun=20567189, nargs=0,
arg_vector=0x88d4e4) at eval.c:3174
#44 0x01038113 in Ffuncall (nargs=1, args=0x88d4e0) at eval.c:3058
#45 0x01124959 in exec_byte_code (bytestr=55203873, vector=56207365,
maxdepth=36, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#46 0x01038c78 in funcall_lambda (fun=56616997, nargs=4,
arg_vector=0x88d754) at eval.c:3240
#47 0x01038113 in Ffuncall (nargs=5, args=0x88d750) at eval.c:3058
#48 0x01124959 in exec_byte_code (bytestr=55220513, vector=56115845,
maxdepth=20, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#49 0x01123f0a in Fbyte_code (bytestr=55220513, vector=56115845,
maxdepth=20) at bytecode.c:423
#50 0x01035e98 in eval_sub (form=54813086) at eval.c:2363
#51 0x01033424 in internal_catch (tag=55370426, func=0x103547a
<eval_sub>, arg=54813086) at eval.c:1247
#52 0x011251ad in exec_byte_code (bytestr=55220593, vector=56617093,
maxdepth=8, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:966
#53 0x01123f0a in Fbyte_code (bytestr=55220593, vector=56617093,
maxdepth=8) at bytecode.c:423
#54 0x01035e98 in eval_sub (form=54813166) at eval.c:2363
#55 0x0103395a in internal_lisp_condition_case (var=53151770,
bodyform=54813166, handlers=54813054) at eval.c:1440
#56 0x01125214 in exec_byte_code (bytestr=55220817, vector=55929221,
maxdepth=28, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:981
#57 0x01038c78 in funcall_lambda (fun=56617189, nargs=0,
arg_vector=0x88e0c8) at eval.c:3240
#58 0x01038113 in Ffuncall (nargs=1, args=0x88e0c4) at eval.c:3058
#59 0x01036c72 in funcall_nil (nargs=1, args=0x88e0c4) at eval.c:2526
#60 0x010370db in run_hook_with_args (nargs=1, args=0x88e0c4,
funcall=0x1036c5a <funcall_nil>) at eval.c:2715
#61 0x01036cbc in Frun_hooks (nargs=1, args=0x88e174) at eval.c:2553
#62 0x01037a78 in Ffuncall (nargs=2, args=0x88e170) at eval.c:2991
#63 0x01124959 in exec_byte_code (bytestr=55221073, vector=53285573,
maxdepth=8, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#64 0x01038c78 in funcall_lambda (fun=56617893, nargs=0,
arg_vector=0x88e3f4) at eval.c:3240
#65 0x01038113 in Ffuncall (nargs=1, args=0x88e3f0) at eval.c:3058
#66 0x010371d9 in call0 (fn=56617893) at eval.c:2763
#67 0x0100772d in safe_run_hooks_1 () at keyboard.c:1868
#68 0x01033a64 in internal_condition_case (bfun=0x10076b0
<safe_run_hooks_1>, handlers=53151794, hfun=0x100772f
<safe_run_hooks_error>)
    at eval.c:1493
#69 0x01007b5b in safe_run_hook_funcall (nargs=1, args=0x88e590) at
keyboard.c:1923
#70 0x010370db in run_hook_with_args (nargs=1, args=0x88e590,
funcall=0x1007aa1 <safe_run_hook_funcall>) at eval.c:2715
#71 0x01007baa in safe_run_hooks (hook=56617893) at keyboard.c:1940
#72 0x01006461 in command_loop_1 () at keyboard.c:1586
#73 0x01033a64 in internal_condition_case (bfun=0x100545f
<command_loop_1>, handlers=53209522, hfun=0x1004c89 <cmd_error>) at
eval.c:1493
#74 0x010050c5 in command_loop_2 (ignore=53151770) at keyboard.c:1156
#75 0x01033424 in internal_catch (tag=53301730, func=0x10050a2
<command_loop_2>, arg=53151770) at eval.c:1247
#76 0x0100502c in command_loop () at keyboard.c:1121
#77 0x01004647 in recursive_edit_1 () at keyboard.c:756
#78 0x011059d7 in read_minibuf (map=53496798, initial=53151770,
prompt=56021441, backup_n=53151770, expflag=0, histvar=53327474,
histpos=0,
    defalt=53151770, allow_props=0, inherit_input_method=0) at minibuf.c:663
#79 0x0110672a in Fread_from_minibuffer (prompt=56021441,
initial_contents=53151770, keymap=53496798, sys_read=53151770,
hist=53151770,
    default_value=53151770, inherit_input_method=53151770) at minibuf.c:957
#80 0x01038024 in Ffuncall (nargs=8, args=0x88ea58) at eval.c:3035
#81 0x01124959 in exec_byte_code (bytestr=20583305, vector=20583389,
maxdepth=72, args_template=8200, nargs=8, args=0x88ece4) at
bytecode.c:785
#82 0x010387f8 in funcall_lambda (fun=20583277, nargs=8,
arg_vector=0x88ecc4) at eval.c:3174
#83 0x01038113 in Ffuncall (nargs=9, args=0x88ecc0) at eval.c:3058
#84 0x01108b01 in Fcompleting_read (prompt=56021441,
collection=57786174, predicate=53151770, require_match=53151770,
initial_input=53151770,
    hist=53151770, def=53151770, inherit_input_method=53151770) at
minibuf.c:1702
#85 0x010380cb in Ffuncall (nargs=3, args=0x88edd0) at eval.c:3042
#86 0x01124959 in exec_byte_code (bytestr=20387729, vector=20387805,
maxdepth=32, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#87 0x01038c78 in funcall_lambda (fun=20387701, nargs=2,
arg_vector=0x88f034) at eval.c:3240
#88 0x01038113 in Ffuncall (nargs=3, args=0x88f030) at eval.c:3058
#89 0x01124959 in exec_byte_code (bytestr=20388425, vector=20388517,
maxdepth=16, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#90 0x01038c78 in funcall_lambda (fun=20388397, nargs=1,
arg_vector=0x88f1f0) at eval.c:3240
#91 0x01038448 in apply_lambda (fun=20388397, args=20382790) at eval.c:3117
#92 0x010361ba in eval_sub (form=20382782) at eval.c:2402
#93 0x01035469 in Feval (form=20382782, lexical=53151770) at eval.c:2211
#94 0x01121b49 in Fcall_interactively (function=54369026,
record_flag=53151794, keys=53172997) at callint.c:346
#95 0x01037dec in Ffuncall (nargs=4, args=0x88f640) at eval.c:3016
#96 0x01037287 in call3 (fn=53316994, arg1=54369026, arg2=53151794,
arg3=53151770) at eval.c:2809
#97 0x0101ffc1 in Fcommand_execute (cmd=54369026,
record_flag=53151794, keys=53151770, special=53151770) at
keyboard.c:10274
#98 0x010202bd in Fexecute_extended_command (prefixarg=53151770) at
keyboard.c:10363
#99 0x01037d0c in Ffuncall (nargs=2, args=0x88f880) at eval.c:3009
#100 0x01123986 in Fcall_interactively (function=53207762,
record_flag=53151770, keys=53172997) at callint.c:857
#101 0x01037dec in Ffuncall (nargs=4, args=0x88fb20) at eval.c:3016
#102 0x01037287 in call3 (fn=53316994, arg1=53207762, arg2=53151770,
arg3=53151770) at eval.c:2809
#103 0x0101ffc1 in Fcommand_execute (cmd=53207762,
record_flag=53151770, keys=53151770, special=53151770) at
keyboard.c:10274
#104 0x01006422 in command_loop_1 () at keyboard.c:1572
#105 0x01033a64 in internal_condition_case (bfun=0x100545f
<command_loop_1>, handlers=53209522, hfun=0x1004c89 <cmd_error>) at
eval.c:1493
#106 0x010050c5 in command_loop_2 (ignore=53151770) at keyboard.c:1156
#107 0x01033424 in internal_catch (tag=53207546, func=0x10050a2
<command_loop_2>, arg=53151770) at eval.c:1247
#108 0x0100507d in command_loop () at keyboard.c:1135
#109 0x01004647 in recursive_edit_1 () at keyboard.c:756
#110 0x01004969 in Frecursive_edit () at keyboard.c:820
#111 0x010027eb in main (argc=4, argv=0xa52d70) at emacs.c:1701

Lisp Backtrace:
"all-completions" (0x88ba88)
"completion-pcm--all-completions" (0x88bce8)
0x34e9420 PVEC_COMPILED
"funcall" (0x88bf50)
"completion-pcm--find-all-completions" (0x88c424)
"completion-pcm-all-completions" (0x88c698)
0x35e23e0 PVEC_COMPILED
0x3418f60 PVEC_COMPILED
"funcall" (0x88cb60)
"completion--some" (0x88cfe8)
"completion-all-completions" (0x88d264)
"completion-all-sorted-completions" (0x88d4e4)
"icomplete-completions" (0x88d754)
"byte-code" (0x88d930)
"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)
(gdb)


I still have the debugger session open. Do you want me to try something?

   J

Message #17 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 14:12:28 +0200

On Fri, Jul 15, 2011 at 09:30, martin rudalics <rudalics <at> gmx.at> wrote:

> Does it get more meaningful when you evaluate `icomplete-exhibit' before
> running the code?

Do you mean doing

  M-: (icomplete-exhibit) <RET>

before trying to crash Emacs?

    Juanma

Message #20 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 14:15:42 +0200

On Fri, Jul 15, 2011 at 14:11, Juanma Barranquero <lekktu <at> gmail.com> wrote:

> #7  0x0114eb0c in re_match_2_internal (bufp=0x1637588, string1=0x0, size1=0,
>    string2=0x4e1d190
> "-outline-Gabriola-normal-normal-normal-decorative-*-*-*-*-p-*-iso8859-7",
> size2=71, pos=0, regs=0x1638de8, stop=71)
>    at regex.c:6280
> #8  0x01144622 in re_search_2 (bufp=0x1637588, str1=0x0, size1=0,
>    str2=0x4e1d190
> "-outline-Gabriola-normal-normal-normal-decorative-*-*-*-*-p-*-iso8859-7",
> size2=71, startpos=0, range=0, regs=0x1638de8,
>    stop=71) at regex.c:4514
> #9  0x01143525 in re_search (bufp=0x1637588, string=0x4e1d190
> "-outline-Gabriola-normal-normal-normal-decorative-*-*-*-*-p-*-iso8859-7",
> size=71,
>    startpos=0, range=71, regs=0x1638de8) at regex.c:4295

Interesting, because at that moment the minibuffer read

  Set font attributes of face `font-lock-comment-face' from font:
-outline-Droid sans[-]bold-normal-normal-mono-*-*-*-*-c-*-iso10646-1
(No matches)

where [-] is the cursor over a dash.

    Juanma

Message #23 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 14:23:46 +0200

> Do you mean doing
> 
>   M-: (icomplete-exhibit) <RET>
> 
> before trying to crash Emacs?

No.  I meant running icomplete-exhibit non-byte-compiled.
But I suppose it's not important any more now.

martin

Message #26 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 15:29:06 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 15 Jul 2011 14:11:22 +0200
> Cc: 9087 <at> debbugs.gnu.org
> 
> #0  w32_abort () at w32fns.c:7182
> #1  0x0103a942 in xfree (block=0x32d4f80) at alloc.c:713

AFAIU, this abort means that we call UNBLOCK_INPUT without a paired
BLOCK_INPUT.

Could you perhaps repeat the recipe after setting a watchpoint on the
variable interrupt_input_blocked, with commands like this:

  p interrupt_input_blocked
  bt 5
  continue

Then GDB should show who calls BLOCK_INPUT and UNBLOCK_INPUT, and if
we are lucky, we will see the unpaired call.

Message #29 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 17:12:41 +0200

On Fri, Jul 15, 2011 at 14:29, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Could you perhaps repeat the recipe after setting a watchpoint on the
> variable interrupt_input_blocked, with commands like this:
>
>  p interrupt_input_blocked
>  bt 5
>  continue

I'm sorry, I think you'll have to downgrade your expectations about my
GDB-foo and explain things more slowly and with easy words ;-)

    Juanma

Message #32 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 18:24:03 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 15 Jul 2011 17:12:41 +0200
> Cc: 9087 <at> debbugs.gnu.org
> 
> On Fri, Jul 15, 2011 at 14:29, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Could you perhaps repeat the recipe after setting a watchpoint on the
> > variable interrupt_input_blocked, with commands like this:
> >
> >  p interrupt_input_blocked
> >  bt 5
> >  continue
> 
> I'm sorry, I think you'll have to downgrade your expectations about my
> GDB-foo and explain things more slowly and with easy words ;-)

Compliance!

 whatever> gdb ./oo/i386/emacs.exe
 (gdb) watch interrupt_input_blocked
 (gdb) commands
  >p interrupt_input_blocked
  >bt 5
  >continue
  >end
 (gdb) run ....

Now each time interrupt_input_blocked will change its value, GDB will
kick in, perform the named "commands", and let Emacs continue.  Do
whatever you need to reproduce the crash, then look at what GDB
printed, and see if the increments/decrements of this variable come in
pairs, as they should, or not.  Note that they could be nested, so
just 2 increments in a row are okay if there are 2 decrements in a row
after that.

See the definitions of BLOCK_INPUT and UNBLOCK_INPUT, for more
insight.

Message #35 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 18:39:57 +0200

On Fri, Jul 15, 2011 at 17:24, Eli Zaretskii <eliz <at> gnu.org> wrote:

>  (gdb) commands
>  >p interrupt_input_blocked
>  >bt 5
>  >continue
>  >end

Well, don't laugh too hard: I didn't know you could do that with a
watchpoint. Cool.

Still, starting from the beginning it does not work:

(gdb) run -Q -f icomplete-mode
Starting program: C:\Devel\emacs\repo\debug\src/..\bin\emacs.exe -Q -f
icomplete-mode
[New Thread 1884.0x678]
Hardware watchpoint 3: interrupt_input_blocked

Old value = 0
New value = 1
xmalloc (size=16) at alloc.c:673
673       val = (POINTER_TYPE *) malloc (size);
$1 = 1
#0  xmalloc (size=16) at alloc.c:673
#1  0x0100280a in sort_args (argc=4, argv=0x9e2d70) at emacs.c:1831

Lisp Backtrace:
Cannot access memory at address 0x730077
(gdb)

and so it does not continue. So I tried starting Emacs, interrupting
it with C-c, setting the watchpoint and continuing. I was able to
crash emacs but the watchpoint for interrupt_input_blocked was
apparently not triggered.

    Juanma

Message #38 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 18:40:35 +0200

On Fri, Jul 15, 2011 at 14:23, martin rudalics <rudalics <at> gmx.at> wrote:

> No.  I meant running icomplete-exhibit non-byte-compiled.

In that case, I cannot make Emacs crash.

    Juanma

Message #41 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 15 Jul 2011 20:12:47 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 15 Jul 2011 18:39:57 +0200
> Cc: 9087 <at> debbugs.gnu.org
> 
> Hardware watchpoint 3: interrupt_input_blocked
> 
> Old value = 0
> New value = 1
> xmalloc (size=16) at alloc.c:673
> 673       val = (POINTER_TYPE *) malloc (size);
> $1 = 1
> #0  xmalloc (size=16) at alloc.c:673
> #1  0x0100280a in sort_args (argc=4, argv=0x9e2d70) at emacs.c:1831
> 
> Lisp Backtrace:
> Cannot access memory at address 0x730077
> (gdb)
> 
> and so it does not continue.

src/.gdbinit defines a hookpost-backtrace command that invokes
xbacktrace, which fails here.  To avoid the above, either redefine
hookpost-backtrace to an empty command (after starting GDB), or start
GDB from a directory other than Emacs's src/, so .gdbinit isn't read.
(You can always read it later, with the `source' command, if needed.)

Message #44 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sun, 17 Jul 2011 01:19:07 +0200

On Fri, Jul 15, 2011 at 17:24, Eli Zaretskii <eliz <at> gnu.org> wrote:

>  whatever> gdb ./oo/i386/emacs.exe
>  (gdb) watch interrupt_input_blocked
>  (gdb) commands
>  >p interrupt_input_blocked
>  >bt 5
>  >continue
>  >end
>  (gdb) run ....
>
> Now each time interrupt_input_blocked will change its value, GDB will
> kick in, perform the named "commands", and let Emacs continue.

It seems like doing that from the start is not a good idea. I stopped
my Emacs before I was able to type commands, and already the
watchpoint commands had been executed 1,663,201 times... (I have a
0,95 GiB log file to prove it :-)

If, however, I start "emacs -Q -f icomplete-mode", then stop it, set
the watchpoint and run it again, the watchpoint is never executed
before the crash.

But I think the whole BLOCK_INPUT/UNBLOCK_INPUT might be a red
herring. I think is some memory corruption, and that's why it does not
always crashes at the same place. For example, I just got this one:

Starting program: C:\emacs\debug\src/..\bin\emacs.exe -Q -f icomplete-mode
[New Thread 5400.0x1594]
[New Thread 5400.0x110c]
[New Thread 5400.0xce8]
[New Thread 5400.0xfdc]
[New Thread 5400.0x17f4]
[Switching to Thread 5400.0x17f4]
0x774c01c4 in ntdll!LdrFindResource_U () from C:\Windows\system32\ntdll.dll
Quit (expect signal SIGINT when the program is resumed)
(gdb) watch interrupt_input_blocked
Hardware watchpoint 3: interrupt_input_blocked
(gdb) commands
Type commands for breakpoint(s) 3, one per line.
End with a line saying just "end".
>p interrupt_input_blocked
>bt 5
>cont
>end
(gdb) p interrupt_input_blocked
$1 = 0
(gdb) cont
Continuing.
[New Thread 5400.0x173c]
[New Thread 5400.0x14ec]
[New Thread 5400.0x13f8]
[Switching to Thread 5400.0xce8]

Breakpoint 1, w32_abort () at w32fns.c:7182
7182      button = MessageBox (NULL,
(gdb) bt
#0  w32_abort () at w32fns.c:7182
#1  0x011d4c94 in Fframe_first_window (frame_or_window=56209413) at window.c:249
#2  0x0110457b in choose_minibuf_frame () at minibuf.c:133
#3  0x011045e3 in choose_minibuf_frame_1 (ignore=53151770) at minibuf.c:140
#4  0x01039a41 in unbind_to (count=27, value=53151770) at eval.c:3437
#5  0x010334d9 in unwind_to_catch (catch=0x88e450, value=53436670) at
eval.c:1290
#6  0x0103403a in Fsignal (error_symbol=53209954, data=53151770) at eval.c:1748
#7  0x010340ed in xsignal (error_symbol=53209954, data=53151770) at eval.c:1769
#8  0x0103410c in xsignal0 (error_symbol=53209954) at eval.c:1778
#9  0x0126224e in text_read_only (propval=53151794) at textprop.c:92
#10 0x01269a74 in verify_interval_modification (buf=0x35b1800,
start=1, end=114) at textprop.c:2157
#11 0x011121f3 in prepare_to_modify_buffer (start=1, end=114,
preserve_ptr=0x7481f83c) at insdel.c:1851
#12 0x011117c1 in del_range_1 (from=1, to=114, prepare=1,
ret_string=0) at insdel.c:1601
#13 0x0111174a in del_range (from=1, to=114) at insdel.c:1576
#14 0x010bfc20 in Ferase_buffer () at buffer.c:1950
#15 0x011064c8 in read_minibuf_unwind (data=53151770) at minibuf.c:864
#16 0x01039a41 in unbind_to (count=27, value=53151770) at eval.c:3437
#17 0x010334d9 in unwind_to_catch (catch=0x88d9f0, value=53151794) at
eval.c:1290
#18 0x01033577 in Fthrow (tag=56259586, value=53151794) at eval.c:1328
#19 0x0122260d in signal_user_input () at w32fns.c:2482
#20 0x012226aa in post_character_message (hwnd=0x6c035c, msg=258,
wParam=117, lParam=1441793, modifiers=0) at w32fns.c:2542
#21 0x012236eb in w32_wnd_proc (hwnd=0x6c035c, msg=258, wParam=117,
lParam=1441793) at w32fns.c:2913
#22 0x767162fa in USER32!OffsetRect () from C:\Windows\syswow64\user32.dll
#23 0x006c035c in ?? ()
#24 0x00000102 in ?? ()
#25 0x00000075 in ?? ()
#26 0x00160001 in ?? ()
#27 0x012226d3 in post_character_message (hwnd=0x12226d3, msg=7078748,
wParam=258, lParam=117, modifiers=1441793) at w32fns.c:2546
#28 0x76716d3a in USER32!IsWindow () from C:\Windows\syswow64\user32.dll
#29 0x012226d3 in post_character_message (hwnd=0x0, msg=19015379,
wParam=7078748, lParam=258, modifiers=117) at w32fns.c:2546
#30 0x767177c4 in USER32!AnyPopup () from C:\Windows\syswow64\user32.dll
#31 0x00000000 in ?? ()
(gdb) bt
#0  w32_abort () at w32fns.c:7182
#1  0x011ef3d0 in Fset_window_configuration (configuration=56085445)
at window.c:5720
#2  0x01039a41 in unbind_to (count=34, value=53151770) at eval.c:3437
#3  0x010334d9 in unwind_to_catch (catch=0x88d9f0, value=53151794) at
eval.c:1290
#4  0x01033577 in Fthrow (tag=56259586, value=53151794) at eval.c:1328
#5  0x0114eb0c in re_match_2_internal (bufp=0x1638b78, string1=0x0, size1=0,
    string2=0x4c52ef0 "-outline-Liberation
Serif-bold-normal-normal-serif-*-*-*-*-p-*-iso8859-7", size2=72,
pos=0, regs=0x1638de8, stop=72)
    at regex.c:6280
#6  0x01144622 in re_search_2 (bufp=0x1638b78, str1=0x0, size1=0,
    str2=0x4c52ef0 "-outline-Liberation
Serif-bold-normal-normal-serif-*-*-*-*-p-*-iso8859-7", size2=72,
startpos=0, range=0, regs=0x1638de8,
    stop=72) at regex.c:4514
#7  0x01143525 in re_search (bufp=0x1638b78, string=0x4c52ef0
"-outline-Liberation
Serif-bold-normal-normal-serif-*-*-*-*-p-*-iso8859-7", size=72,
    startpos=0, range=72, regs=0x1638de8) at regex.c:4295
#8  0x010f9ba3 in string_match_1 (regexp=56277489, string=55222961,
start=0, posix=0) at search.c:411
#9  0x010f9cdc in Fstring_match (regexp=56277489, string=55222961,
start=0) at search.c:451
#10 0x011088fd in Fall_completions (string=20058337,
collection=57679878, predicate=53151770, hide_spaces=53151770) at
minibuf.c:1590
#11 0x01037e6b in Ffuncall (nargs=4, args=0x88ba84) at eval.c:3020
#12 0x01124959 in exec_byte_code (bytestr=20580889, vector=20580957,
maxdepth=48, args_template=4112, nargs=4, args=0x88bcf8) at
bytecode.c:785
#13 0x010387f8 in funcall_lambda (fun=20580861, nargs=4,
arg_vector=0x88bce8) at eval.c:3174
#14 0x01038113 in Ffuncall (nargs=5, args=0x88bce4) at eval.c:3058
#15 0x01124959 in exec_byte_code (bytestr=20581785, vector=54683493,
maxdepth=24, args_template=0, nargs=0, args=0x88bf54) at
bytecode.c:785
#16 0x010387f8 in funcall_lambda (fun=54681829, nargs=0,
arg_vector=0x88bf54) at eval.c:3174
#17 0x01038113 in Ffuncall (nargs=1, args=0x88bf50) at eval.c:3058
#18 0x01035bd9 in eval_sub (form=53438006) at eval.c:2329
#19 0x0103395a in internal_lisp_condition_case (var=54352858,
bodyform=53438006, handlers=53437654) at eval.c:1440
#20 0x01125214 in exec_byte_code (bytestr=20581449, vector=20581629,
maxdepth=144, args_template=5136, nargs=4, args=0x88c434) at
bytecode.c:981
#21 0x010387f8 in funcall_lambda (fun=20581421, nargs=4,
arg_vector=0x88c424) at eval.c:3174
#22 0x01038113 in Ffuncall (nargs=5, args=0x88c420) at eval.c:3058
#23 0x01124959 in exec_byte_code (bytestr=20581897, vector=20581949,
maxdepth=56, args_template=4112, nargs=4, args=0x88c6a8) at
bytecode.c:785
#24 0x010387f8 in funcall_lambda (fun=20581869, nargs=4,
arg_vector=0x88c698) at eval.c:3174
#25 0x01038113 in Ffuncall (nargs=5, args=0x88c694) at eval.c:3058
#26 0x01124959 in exec_byte_code (bytestr=20565865, vector=54680037,
maxdepth=24, args_template=1028, nargs=1, args=0x88c8fc) at
bytecode.c:785
#27 0x010387f8 in funcall_lambda (fun=54712581, nargs=1,
arg_vector=0x88c8f8) at eval.c:3174
#28 0x01038113 in Ffuncall (nargs=2, args=0x88c8f4) at eval.c:3058
#29 0x01124959 in exec_byte_code (bytestr=20561185, vector=55622469,
maxdepth=20, args_template=0, nargs=0, args=0x88cb64) at
bytecode.c:785
#30 0x010387f8 in funcall_lambda (fun=55622213, nargs=0,
arg_vector=0x88cb64) at eval.c:3174
#31 0x01038113 in Ffuncall (nargs=1, args=0x88cb60) at eval.c:3058
#32 0x01035bd9 in eval_sub (form=53136638) at eval.c:2329
#33 0x0103395a in internal_lisp_condition_case (var=53801322,
bodyform=53136638, handlers=53129382) at eval.c:1440
#34 0x01125214 in exec_byte_code (bytestr=20561009, vector=20561109,
maxdepth=60, args_template=2056, nargs=2, args=0x88cff0) at
bytecode.c:981
#35 0x010387f8 in funcall_lambda (fun=20560981, nargs=2,
arg_vector=0x88cfe8) at eval.c:3174
#36 0x01038113 in Ffuncall (nargs=3, args=0x88cfe4) at eval.c:3058
#37 0x01124959 in exec_byte_code (bytestr=20565513, vector=20565813,
maxdepth=60, args_template=5136, nargs=5, args=0x88d278) at
bytecode.c:785
#38 0x010387f8 in funcall_lambda (fun=20565725, nargs=5,
arg_vector=0x88d264) at eval.c:3174
#39 0x01038113 in Ffuncall (nargs=6, args=0x88d260) at eval.c:3058
#40 0x01124959 in exec_byte_code (bytestr=20567769, vector=20567917,
maxdepth=72, args_template=0, nargs=0, args=0x88d4e4) at
bytecode.c:785
#41 0x010387f8 in funcall_lambda (fun=20567741, nargs=0,
arg_vector=0x88d4e4) at eval.c:3174
#42 0x01038113 in Ffuncall (nargs=1, args=0x88d4e0) at eval.c:3058
#43 0x01124959 in exec_byte_code (bytestr=55187489, vector=56338437,
maxdepth=36, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#44 0x01038c78 in funcall_lambda (fun=54991109, nargs=4,
arg_vector=0x88d754) at eval.c:3240
#45 0x01038113 in Ffuncall (nargs=5, args=0x88d750) at eval.c:3058
#46 0x01124959 in exec_byte_code (bytestr=55204129, vector=56251013,
maxdepth=20, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#47 0x01123f0a in Fbyte_code (bytestr=55204129, vector=56251013,
maxdepth=20) at bytecode.c:423
#48 0x01035e98 in eval_sub (form=57841918) at eval.c:2363
#49 0x01033424 in internal_catch (tag=56259586, func=0x103547a
<eval_sub>, arg=57841918) at eval.c:1247
#50 0x011251ad in exec_byte_code (bytestr=55204209, vector=54990245,
maxdepth=8, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:966
#51 0x01123f0a in Fbyte_code (bytestr=55204209, vector=54990245,
maxdepth=8) at bytecode.c:423
#52 0x01035e98 in eval_sub (form=57841982) at eval.c:2363
#53 0x0103395a in internal_lisp_condition_case (var=53151770,
bodyform=57841982, handlers=57841886) at eval.c:1440
#54 0x01125214 in exec_byte_code (bytestr=55204433, vector=56072581,
maxdepth=28, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:981
#55 0x01038c78 in funcall_lambda (fun=54989701, nargs=0,
arg_vector=0x88e0c8) at eval.c:3240
#56 0x01038113 in Ffuncall (nargs=1, args=0x88e0c4) at eval.c:3058
#57 0x01036c72 in funcall_nil (nargs=1, args=0x88e0c4) at eval.c:2526
#58 0x010370db in run_hook_with_args (nargs=1, args=0x88e0c4,
funcall=0x1036c5a <funcall_nil>) at eval.c:2715
#59 0x01036cbc in Frun_hooks (nargs=1, args=0x88e174) at eval.c:2553
#60 0x01037a78 in Ffuncall (nargs=2, args=0x88e170) at eval.c:2991
#61 0x01124959 in exec_byte_code (bytestr=55204689, vector=53285573,
maxdepth=8, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#62 0x01038c78 in funcall_lambda (fun=54990853, nargs=0,
arg_vector=0x88e3f4) at eval.c:3240
#63 0x01038113 in Ffuncall (nargs=1, args=0x88e3f0) at eval.c:3058
#64 0x010371d9 in call0 (fn=54990853) at eval.c:2763
#65 0x0100772d in safe_run_hooks_1 () at keyboard.c:1868
#66 0x01033a64 in internal_condition_case (bfun=0x10076b0
<safe_run_hooks_1>, handlers=53151794, hfun=0x100772f
<safe_run_hooks_error>)
    at eval.c:1493
#67 0x01007b5b in safe_run_hook_funcall (nargs=1, args=0x88e590) at
keyboard.c:1923
#68 0x010370db in run_hook_with_args (nargs=1, args=0x88e590,
funcall=0x1007aa1 <safe_run_hook_funcall>) at eval.c:2715
#69 0x01007baa in safe_run_hooks (hook=54990853) at keyboard.c:1940
#70 0x01006461 in command_loop_1 () at keyboard.c:1586
#71 0x01033a64 in internal_condition_case (bfun=0x100545f
<command_loop_1>, handlers=53209522, hfun=0x1004c89 <cmd_error>) at
eval.c:1493
#72 0x010050c5 in command_loop_2 (ignore=53151770) at keyboard.c:1156
#73 0x01033424 in internal_catch (tag=53301730, func=0x10050a2
<command_loop_2>, arg=53151770) at eval.c:1247
#74 0x0100502c in command_loop () at keyboard.c:1121
#75 0x01004647 in recursive_edit_1 () at keyboard.c:756
#76 0x011059d7 in read_minibuf (map=53496782, initial=53151770,
prompt=80803073, backup_n=53151770, expflag=0, histvar=53327474,
histpos=0,
    defalt=53151770, allow_props=0, inherit_input_method=0) at minibuf.c:663
#77 0x0110672a in Fread_from_minibuffer (prompt=80803073,
initial_contents=53151770, keymap=53496782, sys_read=53151770,
hist=53151770,
    default_value=53151770, inherit_input_method=53151770) at minibuf.c:957
#78 0x01038024 in Ffuncall (nargs=8, args=0x88ea58) at eval.c:3035
#79 0x01124959 in exec_byte_code (bytestr=20583857, vector=20583941,
maxdepth=72, args_template=8200, nargs=8, args=0x88ece4) at
bytecode.c:785
#80 0x010387f8 in funcall_lambda (fun=20583829, nargs=8,
arg_vector=0x88ecc4) at eval.c:3174
#81 0x01038113 in Ffuncall (nargs=9, args=0x88ecc0) at eval.c:3058
#82 0x01108b01 in Fcompleting_read (prompt=80803073,
collection=57679878, predicate=53151770, require_match=53151770,
initial_input=53151770,
    hist=53151770, def=53151770, inherit_input_method=53151770) at
minibuf.c:1702
#83 0x010380cb in Ffuncall (nargs=3, args=0x88edd0) at eval.c:3042
#84 0x01124959 in exec_byte_code (bytestr=20388249, vector=20388325,
maxdepth=32, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#85 0x01038c78 in funcall_lambda (fun=20388221, nargs=2,
arg_vector=0x88f034) at eval.c:3240
#86 0x01038113 in Ffuncall (nargs=3, args=0x88f030) at eval.c:3058
#87 0x01124959 in exec_byte_code (bytestr=20388945, vector=20389037,
maxdepth=16, args_template=53151770, nargs=0, args=0x0) at
bytecode.c:785
#88 0x01038c78 in funcall_lambda (fun=20388917, nargs=1,
arg_vector=0x88f1f0) at eval.c:3240
#89 0x01038448 in apply_lambda (fun=20388917, args=20383310) at eval.c:3117
#90 0x010361ba in eval_sub (form=20383302) at eval.c:2402
#91 0x01035469 in Feval (form=20383302, lexical=53151770) at eval.c:2211
#92 0x01121b49 in Fcall_interactively (function=53705922,
record_flag=53151794, keys=53172997) at callint.c:346
#93 0x01037dec in Ffuncall (nargs=4, args=0x88f640) at eval.c:3016
#94 0x01037287 in call3 (fn=53316994, arg1=53705922, arg2=53151794,
arg3=53151770) at eval.c:2809
#95 0x0101ffc1 in Fcommand_execute (cmd=53705922,
record_flag=53151794, keys=53151770, special=53151770) at
keyboard.c:10274
#96 0x010202bd in Fexecute_extended_command (prefixarg=53151770) at
keyboard.c:10363
#97 0x01037d0c in Ffuncall (nargs=2, args=0x88f880) at eval.c:3009
#98 0x01123986 in Fcall_interactively (function=53207762,
record_flag=53151770, keys=53172997) at callint.c:857
#99 0x01037dec in Ffuncall (nargs=4, args=0x88fb20) at eval.c:3016
#100 0x01037287 in call3 (fn=53316994, arg1=53207762, arg2=53151770,
arg3=53151770) at eval.c:2809
#101 0x0101ffc1 in Fcommand_execute (cmd=53207762,
record_flag=53151770, keys=53151770, special=53151770) at
keyboard.c:10274
#102 0x01006422 in command_loop_1 () at keyboard.c:1572
#103 0x01033a64 in internal_condition_case (bfun=0x100545f
<command_loop_1>, handlers=53209522, hfun=0x1004c89 <cmd_error>) at
eval.c:1493
#104 0x010050c5 in command_loop_2 (ignore=53151770) at keyboard.c:1156
#105 0x01033424 in internal_catch (tag=53207546, func=0x10050a2
<command_loop_2>, arg=53151770) at eval.c:1247
#106 0x0100507d in command_loop () at keyboard.c:1135
#107 0x01004647 in recursive_edit_1 () at keyboard.c:756
#108 0x01004969 in Frecursive_edit () at keyboard.c:820
#109 0x010027eb in main (argc=4, argv=0xb82d70) at emacs.c:1701
(gdb)

Message #47 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sun, 17 Jul 2011 06:08:37 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sun, 17 Jul 2011 01:19:07 +0200
> Cc: 9087 <at> debbugs.gnu.org
> 
> But I think the whole BLOCK_INPUT/UNBLOCK_INPUT might be a red
> herring.

Wasn't the crash inside UNBLOCK_INPUT?

Message #50 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sun, 17 Jul 2011 11:38:46 +0200

> #0  w32_abort () at w32fns.c:7182
> #1  0x011d4c94 in Fframe_first_window (frame_or_window=56209413) at window.c:249
> #2  0x0110457b in choose_minibuf_frame () at minibuf.c:133
> #3  0x011045e3 in choose_minibuf_frame_1 (ignore=53151770) at minibuf.c:140
> #4  0x01039a41 in unbind_to (count=27, value=53151770) at eval.c:3437
> #5  0x010334d9 in unwind_to_catch (catch=0x88e450, value=53436670) at
> eval.c:1290

This abort seems to come from a frame containing a window which has
neither a buffer nor a child window.

> (gdb) bt
> #0  w32_abort () at w32fns.c:7182
> #1  0x011ef3d0 in Fset_window_configuration (configuration=56085445)
> at window.c:5720
> #2  0x01039a41 in unbind_to (count=34, value=53151770) at eval.c:3437
> #3  0x010334d9 in unwind_to_catch (catch=0x88d9f0, value=53151794) at
> eval.c:1290

OTOH, this one looks like a mismatched UNBLOCK_INPUT.

martin

Message #53 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Mon, 18 Jul 2011 03:59:19 +0200

On Sun, Jul 17, 2011 at 11:38, martin rudalics <rudalics <at> gmx.at> wrote:

> This abort seems to come from a frame containing a window which has
> neither a buffer nor a child window.

All the crashes have been in a single frame, with either one window
(displaying "*scrach*") or two windows (top showing "*scratch*",
bottom showing completions), plus of course the minibuffer. All
starting from "emacs -Q -f icomplete-mode" and doing nothing else but
M-x set-face-font twice.

    Juanma

Message #56 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Mon, 18 Jul 2011 04:07:50 +0200

On Sun, Jul 17, 2011 at 05:08, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Wasn't the crash inside UNBLOCK_INPUT?

Wouldn't this

      --interrupt_input_blocked;

have triggered the interrupt_input_blocked watchpoint?

    Juanma

Message #59 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Mon, 18 Jul 2011 06:01:27 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 18 Jul 2011 04:07:50 +0200
> Cc: 9087 <at> debbugs.gnu.org
> 
> On Sun, Jul 17, 2011 at 05:08, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Wasn't the crash inside UNBLOCK_INPUT?
> 
> Wouldn't this
> 
>       --interrupt_input_blocked;
> 
> have triggered the interrupt_input_blocked watchpoint?

It should have.  But if the abort was not in UNBLOCK_INPUT, then I
don't understand the backtrace you posted: where else is the call to
`abort', if not inside UNBLOCK_INPUT?

Message #62 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Mon, 18 Jul 2011 13:53:47 +0200

On Mon, Jul 18, 2011 at 05:01, Eli Zaretskii <eliz <at> gnu.org> wrote:

> It should have.  But if the abort was not in UNBLOCK_INPUT, then I
> don't understand the backtrace you posted: where else is the call to
> `abort', if not inside UNBLOCK_INPUT?

If you're talking about this crash:

Breakpoint 1, w32_abort () at w32fns.c:7182
7182      button = MessageBox (NULL,
(gdb) bt
#0  w32_abort () at w32fns.c:7182
#1  0x0103a942 in xfree (block=0x32d4f80) at alloc.c:713
#2  0x01004b8d in pop_kboard () at keyboard.c:923
[etc]

yes, it happens in UNBLOCK_INPUT, and at this moment I wasn't using
watchpoints. But in this one

Breakpoint 1, w32_abort () at w32fns.c:7182
7182      button = MessageBox (NULL,
(gdb) bt
#0  w32_abort () at w32fns.c:7182
#1  0x011d4c94 in Fframe_first_window (frame_or_window=56209413) at window.c:249
#2  0x0110457b in choose_minibuf_frame () at minibuf.c:133
#3  0x011045e3 in choose_minibuf_frame_1 (ignore=53151770) at minibuf.c:140
#4  0x01039a41 in unbind_to (count=27, value=53151770) at eval.c:3437
#5  0x010334d9 in unwind_to_catch (catch=0x88e450, value=53436670) at
eval.c:1290
#6  0x0103403a in Fsignal (error_symbol=53209954, data=53151770) at eval.c:1748
#7  0x010340ed in xsignal (error_symbol=53209954, data=53151770) at eval.c:1769
#8  0x0103410c in xsignal0 (error_symbol=53209954) at eval.c:1778
#9  0x0126224e in text_read_only (propval=53151794) at textprop.c:92
#10 0x01269a74 in verify_interval_modification (buf=0x35b1800,
start=1, end=114) at textprop.c:2157
#11 0x011121f3 in prepare_to_modify_buffer (start=1, end=114,
preserve_ptr=0x7481f83c) at insdel.c:1851
#12 0x011117c1 in del_range_1 (from=1, to=114, prepare=1,
ret_string=0) at insdel.c:1601
#13 0x0111174a in del_range (from=1, to=114) at insdel.c:1576
#14 0x010bfc20 in Ferase_buffer () at buffer.c:1950
#15 0x011064c8 in read_minibuf_unwind (data=53151770) at minibuf.c:864
#16 0x01039a41 in unbind_to (count=27, value=53151770) at eval.c:3437
#17 0x010334d9 in unwind_to_catch (catch=0x88d9f0, value=53151794) at
eval.c:1290
#18 0x01033577 in Fthrow (tag=56259586, value=53151794) at eval.c:1328
#19 0x0122260d in signal_user_input () at w32fns.c:2482
#20 0x012226aa in post_character_message (hwnd=0x6c035c, msg=258,
wParam=117, lParam=1441793, modifiers=0) at w32fns.c:2542
#21 0x012236eb in w32_wnd_proc (hwnd=0x6c035c, msg=258, wParam=117,
lParam=1441793) at w32fns.c:2913
#22 0x767162fa in USER32!OffsetRect () from C:\Windows\syswow64\user32.dll
#23 0x006c035c in ?? ()
#24 0x00000102 in ?? ()
#25 0x00000075 in ?? ()
#26 0x00160001 in ?? ()
#27 0x012226d3 in post_character_message (hwnd=0x12226d3, msg=7078748,
wParam=258, lParam=117, modifiers=1441793) at w32fns.c:2546
#28 0x76716d3a in USER32!IsWindow () from C:\Windows\syswow64\user32.dll
#29 0x012226d3 in post_character_message (hwnd=0x0, msg=19015379,
wParam=7078748, lParam=258, modifiers=117) at w32fns.c:2546
#30 0x767177c4 in USER32!AnyPopup () from C:\Windows\syswow64\user32.dll
#31 0x00000000 in ?? ()

where I did have the interrupt_input_blocked watchpoint set, how do
you know that it was inside UNBLOCK_INPUT?

    Juanma

Message #65 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Mon, 18 Jul 2011 19:45:47 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 18 Jul 2011 13:53:47 +0200
> Cc: 9087 <at> debbugs.gnu.org
> 
> yes, it happens in UNBLOCK_INPUT, and at this moment I wasn't using
> watchpoints. But in this one
> 
> Breakpoint 1, w32_abort () at w32fns.c:7182
> 7182      button = MessageBox (NULL,
> (gdb) bt
> #0  w32_abort () at w32fns.c:7182
> #1  0x011d4c94 in Fframe_first_window (frame_or_window=56209413) at window.c:249
> [...]
> where I did have the interrupt_input_blocked watchpoint set, how do
> you know that it was inside UNBLOCK_INPUT?

It wasn't.  This is the crash about which Martin said that it's with a
window that has no children and no buffer.  So it looks like a
different crash.

Anyway, could you propose an exact recipe to reproduce this?  I tried
using the one you gave originally, but I don't seem to have the fonts
you used, or maybe I'm not following the recipe correctly.  A step by
step recipe using "normal" fonts would be appreciated.

Message #68 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Mon, 18 Jul 2011 19:34:52 +0200

On Mon, Jul 18, 2011 at 18:45, Eli Zaretskii <eliz <at> gnu.org> wrote:

> It wasn't.  This is the crash about which Martin said that it's with a
> window that has no children and no buffer.  So it looks like a
> different crash.

I cannot dismiss the possibility of having found two different bugs at
once, but as I repeat the same steps (allowing for the variation that
the bug does not always happen at the exact same step), it seems like
a long shot.

> Anyway, could you propose an exact recipe to reproduce this?

I can not promise that it will be exact, but the one I give works for
me every time.

>  I tried
> using the one you gave originally, but I don't seem to have the fonts
> you used, or maybe I'm not following the recipe correctly.  A step by
> step recipe using "normal" fonts would be appreciated.

OK, though I'm not sure whether the bug is affected by the contents of
the completion somehow (which surely depends on the fonts installed).

emacs -Q -f icomplete-mode
M-x set-face-font <RET> font-lock-comment-face <RET>
-ou<TAB>Cou<TAB>bo<TAB>no<TAB>iso1<TAB><RET>
M-x set-face-font <RET> M-p <RET> M-p    ; now you have back the font spec
M-f M-f M-f  ; to move just after "Courier New"
M-backspace M-backspace M-backspace  ; to delete "outline-Courier New"

then try to complete with ou<TAB>, then M-backspace to delete
"outline", and repeate a few times. Most of the time it crashes after
a few tries. You can also complete outline and then try with another
font family, but I suggest using one that does not have bold variant,
so the completion does not match.

I think the specific font, and wheter it is bold, normal, or whatever
does not really matter. The only thing that seems to matter is doing
non-matching completions.

Hope you're able to reproduce it.

    Juanma

Message #71 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sun, 14 Aug 2011 16:13:54 -0400

Juanma Barranquero <lekktu <at> gmail.com> writes:

> #0  w32_abort () at w32fns.c:7182
> #1  0x0103a942 in xfree (block=0x32d4f80) at alloc.c:713
> #2  0x01004b8d in pop_kboard () at keyboard.c:923
> #3  0x01004c6a in restore_kboard_configuration (was_locked=53151794)
> at keyboard.c:985

Can you reproducibly get the crash at this particular UNBLOCK_INPUT?

If so, it narrows the problem to one of the functions called between the
BLOCK_INPUT at window.c:5484 and the UNBLOCK_INPUT at window.c:5720.

A possible way to debug this is be to insert code at intervals between
those two lines, to check the value of interrupt_input_blocked and abort
if it ever changes (which would indicate the existence of an extra
UNBLOCK_INPUT).

Message #74 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Wed, 14 Sep 2011 16:43:40 +0200

> Can you reproducibly get the crash at this particular UNBLOCK_INPUT?

No, not at that particular point. But, with the current trunk, I can
get the crash much more easily.

As always, I'm doing

 emacs -Q -f icomplete-mode
 M-x set-face-font <RET> font-lock-comment-face <RET>

and then trying to select a font, by typing part of the spec and
hitting <TAB>. Before, I had to do a weird dance of moving back and
forth to get the crash, but currently I've even had it once or twice
it just by doing

-*C<TAB>

though it does not happen always at the same point. Backtraces are
similar, but not identical. Two follow:

---- First backtrace ----

(gdb) run -Q -f icomplete-mode
Starting program: C:\Devel\emacs\repo\debug\src/..\bin\emacs.exe -Q -f
icomplete-mode
[New Thread 1696.0x1368]
[New Thread 1696.0x130c]
[New Thread 1696.0x758]
gdb: unknown target exception 0xc0000029 at 0x76f407b6

Program received signal ?, Unknown signal.
[Switching to Thread 1696.0x758]
0x76f407b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
(gdb) bt
#0  0x76f407b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
#1  0x0088da00 in ?? ()
#2  0x74d207f0 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)
0x3414ee0 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" (0x88f894)
"call-interactively" (0x88fb34)
(gdb) thread 1
[Switching to thread 1 (Thread 1696.0x1368)]#0  0x010c6064 in
sort_overlays (overlay_vec=0x88ad10, noverlays=0, w=0x38d4600) at
buffer.c:2907
2907      for (i = 0; i < noverlays; i++)
(gdb) bt
#0  0x010c6064 in sort_overlays (overlay_vec=0x88ad10, noverlays=0,
w=0x38d4600) at buffer.c:2907
#1  0x01266844 in get_char_property_and_overlay (position=4,
prop=53440994, object=53368837, overlay=0x88ae24) at textprop.c:627
#2  0x01160b31 in handle_display_prop (it=0x88afa0) at xdisp.c:4067
#3  0x0115dff6 in handle_stop (it=0x88afa0) at xdisp.c:2923
#4  0x011677c2 in reseat (it=0x88afa0, pos=..., force_p=1) at xdisp.c:5828
#5  0x0115d4eb in init_iterator (it=0x88afa0, w=0x38d4600, charpos=1,
bytepos=1, row=0x0, base_face_id=DEFAULT_FACE_ID) at xdisp.c:2633
#6  0x011744f7 in resize_mini_window (w=0x38d4600, exact_p=0) at xdisp.c:9848
#7  0x01107a26 in read_minibuf_unwind (data=53229594) at minibuf.c:882
#8  0x01039db2 in unbind_to (count=36, value=53229594) at eval.c:3398
#9  0x01109f64 in Fall_completions (string=20087009,
collection=53215942, predicate=53229594, hide_spaces=53229594) at
minibuf.c:1635
#10 0x010381a3 in Ffuncall (nargs=4, args=0x88ba84) at eval.c:2977
#11 0x01125f61 in exec_byte_code (bytestr=20594801, vector=20594869,
maxdepth=48, args_template=4112, nargs=4, args=0x88bcf8) at
bytecode.c:785
#12 0x01038b30 in funcall_lambda (fun=20594773, nargs=4,
arg_vector=0x88bce8) at eval.c:3131
#13 0x0103844b in Ffuncall (nargs=5, args=0x88bce4) at eval.c:3015
#14 0x01125f61 in exec_byte_code (bytestr=20595697, vector=55464037,
maxdepth=24, args_template=0, nargs=0, args=0x88bf54) at
bytecode.c:785
#15 0x01038b30 in funcall_lambda (fun=55464549, nargs=0,
arg_vector=0x88bf54) at eval.c:3131
#16 0x0103844b in Ffuncall (nargs=1, args=0x88bf50) at eval.c:3015
#17 0x01035f11 in eval_sub (form=81852606) at eval.c:2286
#18 0x01033c7c in internal_lisp_condition_case (var=54339282,
bodyform=81852606, handlers=81852654) at eval.c:1445
#19 0x0112681c in exec_byte_code (bytestr=20595361, vector=20595541,
maxdepth=144, args_template=5136, nargs=4, args=0x88c434) at
bytecode.c:981
#20 0x01038b30 in funcall_lambda (fun=20595333, nargs=4,
arg_vector=0x88c424) at eval.c:3131
#21 0x0103844b in Ffuncall (nargs=5, args=0x88c420) at eval.c:3015
#22 0x01125f61 in exec_byte_code (bytestr=20595809, vector=20595861,
maxdepth=56, args_template=4112, nargs=4, args=0x88c6a8) at
bytecode.c:785
#23 0x01038b30 in funcall_lambda (fun=20595781, nargs=4,
arg_vector=0x88c698) at eval.c:3131
#24 0x0103844b in Ffuncall (nargs=5, args=0x88c694) at eval.c:3015
#25 0x01125f61 in exec_byte_code (bytestr=20579737, vector=55467685,
maxdepth=24, args_template=1028, nargs=1, args=0x88c8fc) at
bytecode.c:785
#26 0x01038b30 in funcall_lambda (fun=55466437, nargs=1,
arg_vector=0x88c8f8) at eval.c:3131
#27 0x0103844b in Ffuncall (nargs=2, args=0x88c8f4) at eval.c:3015
#28 0x01125f61 in exec_byte_code (bytestr=20575057, vector=55467973,
maxdepth=20, args_template=0, nargs=0, args=0x88cb64) at
bytecode.c:785
#29 0x01038b30 in funcall_lambda (fun=55464581, nargs=0,
arg_vector=0x88cb64) at eval.c:3131
#30 0x0103844b in Ffuncall (nargs=1, args=0x88cb60) at eval.c:3015
#31 0x01035f11 in eval_sub (form=81852462) at eval.c:2286
#32 0x01033c7c in internal_lisp_condition_case (var=54326370,
bodyform=81852462, handlers=81852510) at eval.c:1445
#33 0x0112681c in exec_byte_code (bytestr=20574881, vector=20574981,
maxdepth=60, args_template=2056, nargs=2, args=0x88cff0) at
bytecode.c:981
#34 0x01038b30 in funcall_lambda (fun=20574853, nargs=2,
arg_vector=0x88cfe8) at eval.c:3131
#35 0x0103844b in Ffuncall (nargs=3, args=0x88cfe4) at eval.c:3015
#36 0x01125f61 in exec_byte_code (bytestr=20579385, vector=20579685,
maxdepth=60, args_template=5136, nargs=5, args=0x88d278) at
bytecode.c:785
#37 0x01038b30 in funcall_lambda (fun=20579597, nargs=5,
arg_vector=0x88d264) at eval.c:3131
#38 0x0103844b in Ffuncall (nargs=6, args=0x88d260) at eval.c:3015
#39 0x01125f61 in exec_byte_code (bytestr=20581641, vector=20581789,
maxdepth=72, args_template=0, nargs=0, args=0x88d4e4) at
bytecode.c:785
#40 0x01038b30 in funcall_lambda (fun=20581613, nargs=0,
arg_vector=0x88d4e4) at eval.c:3131
#41 0x0103844b in Ffuncall (nargs=1, args=0x88d4e0) at eval.c:3015
#42 0x01125f61 in exec_byte_code (bytestr=58476945, vector=55233029,
maxdepth=36, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:785
#43 0x01038fb0 in funcall_lambda (fun=54608613, nargs=4,
arg_vector=0x88d754) at eval.c:3197
#44 0x0103844b in Ffuncall (nargs=5, args=0x88d750) at eval.c:3015
#45 0x01125f61 in exec_byte_code (bytestr=58476129, vector=59388421,
maxdepth=20, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:785
#46 0x01125512 in Fbyte_code (bytestr=58476129, vector=59388421,
maxdepth=20) at bytecode.c:423
#47 0x010361d0 in eval_sub (form=57801134) at eval.c:2320
#48 0x01033746 in internal_catch (tag=59394338, func=0x10357b2
<eval_sub>, arg=57801134) at eval.c:1248
#49 0x011267b5 in exec_byte_code (bytestr=58476241, vector=54611109,
maxdepth=8, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:966
#50 0x01125512 in Fbyte_code (bytestr=58476241, vector=54611109,
maxdepth=8) at bytecode.c:423
#51 0x010361d0 in eval_sub (form=57801070) at eval.c:2320
#52 0x01033c7c in internal_lisp_condition_case (var=53229594,
bodyform=57801070, handlers=57801166) at eval.c:1445
#53 0x0112681c in exec_byte_code (bytestr=58476497, vector=55180421,
maxdepth=28, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:981
#54 0x01038fb0 in funcall_lambda (fun=54610405, nargs=0,
arg_vector=0x88e0c8) at eval.c:3197
#55 0x0103844b in Ffuncall (nargs=1, args=0x88e0c4) at eval.c:3015
#56 0x01036faa in funcall_nil (nargs=1, args=0x88e0c4) at eval.c:2483
#57 0x01037413 in run_hook_with_args (nargs=1, args=0x88e0c4,
funcall=0x1036f92 <funcall_nil>) at eval.c:2672
#58 0x01036ff4 in Frun_hooks (nargs=1, args=0x88e174) at eval.c:2510
#59 0x01037db0 in Ffuncall (nargs=2, args=0x88e170) at eval.c:2948
#60 0x01125f61 in exec_byte_code (bytestr=58492129, vector=55213749,
maxdepth=8, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:785
#61 0x01038fb0 in funcall_lambda (fun=54611685, nargs=0,
arg_vector=0x88e3f4) at eval.c:3197
#62 0x0103844b in Ffuncall (nargs=1, args=0x88e3f0) at eval.c:3015
#63 0x01037511 in call0 (fn=54611685) at eval.c:2720
#64 0x010076f1 in safe_run_hooks_1 () at keyboard.c:1869
#65 0x01033d86 in internal_condition_case (bfun=0x1007674
<safe_run_hooks_1>, handlers=53229618, hfun=0x10076f3
<safe_run_hooks_error>)
    at eval.c:1491
#66 0x01007b1f in safe_run_hook_funcall (nargs=1, args=0x88e590) at
keyboard.c:1924
#67 0x01037413 in run_hook_with_args (nargs=1, args=0x88e590,
funcall=0x1007a65 <safe_run_hook_funcall>) at eval.c:2672
#68 0x01007b6e in safe_run_hooks (hook=54611685) at keyboard.c:1941
#69 0x01006425 in command_loop_1 () at keyboard.c:1587
#70 0x01033d86 in internal_condition_case (bfun=0x1005423
<command_loop_1>, handlers=53287322, hfun=0x1004c4d <cmd_error>) at
eval.c:1491
#71 0x01005089 in command_loop_2 (ignore=53229594) at keyboard.c:1157
#72 0x01033746 in internal_catch (tag=53400010, func=0x1005066
<command_loop_2>, arg=53229594) at eval.c:1248
#73 0x01004ff0 in command_loop () at keyboard.c:1122
#74 0x0100460b in recursive_edit_1 () at keyboard.c:756
#75 0x01106eb4 in read_minibuf (map=53697342, initial=53229594,
prompt=53604257, backup_n=53229594, expflag=0, histvar=53425754,
histpos=0,
    defalt=53229594, allow_props=0, inherit_input_method=0) at minibuf.c:673
#76 0x01107c07 in Fread_from_minibuffer (prompt=53604257,
initial_contents=53229594, keymap=53697342, sys_read=53229594,
hist=53229594,
    default_value=53229594, inherit_input_method=53229594) at minibuf.c:966
#77 0x0103835c in Ffuncall (nargs=8, args=0x88ea58) at eval.c:2992
#78 0x01125f61 in exec_byte_code (bytestr=20597785, vector=20597869,
maxdepth=72, args_template=8200, nargs=8, args=0x88ece4) at
bytecode.c:785
#79 0x01038b30 in funcall_lambda (fun=20597757, nargs=8,
arg_vector=0x88ecc4) at eval.c:3131
#80 0x0103844b in Ffuncall (nargs=9, args=0x88ecc0) at eval.c:3015
#81 0x01109fde in Fcompleting_read (prompt=53604257,
collection=53215942, predicate=53229594, require_match=53229594,
initial_input=53229594,
    hist=53229594, def=53229594, inherit_input_method=53229594) at
minibuf.c:1711
#82 0x01038403 in Ffuncall (nargs=3, args=0x88edd0) at eval.c:2999
#83 0x01125f61 in exec_byte_code (bytestr=20401153, vector=20401229,
maxdepth=32, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:785
#84 0x01038fb0 in funcall_lambda (fun=20401125, nargs=2,
arg_vector=0x88f034) at eval.c:3197
#85 0x0103844b in Ffuncall (nargs=3, args=0x88f030) at eval.c:3015
#86 0x01125f61 in exec_byte_code (bytestr=20401849, vector=20401941,
maxdepth=16, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:785
#87 0x01038fb0 in funcall_lambda (fun=20401821, nargs=1,
arg_vector=0x88f1f0) at eval.c:3197
#88 0x01038780 in apply_lambda (fun=20401821, args=20396214) at eval.c:3074
#89 0x010364f2 in eval_sub (form=20396206) at eval.c:2359
#90 0x010357a1 in Feval (form=20396206, lexical=53229594) at eval.c:2168
#91 0x01123141 in Fcall_interactively (function=54284938,
record_flag=53229618, keys=53250821) at callint.c:346
#92 0x01038124 in Ffuncall (nargs=4, args=0x88f640) at eval.c:2973
#93 0x010375bf in call3 (fn=53415274, arg1=54284938, arg2=53229618,
arg3=53229594) at eval.c:2766
#94 0x010200d4 in Fcommand_execute (cmd=54284938,
record_flag=53229618, keys=53229594, special=53229594) at
keyboard.c:10276
#95 0x010203cf in Fexecute_extended_command (prefixarg=53229594) at
keyboard.c:10365
#96 0x01038044 in Ffuncall (nargs=2, args=0x88f890) at eval.c:2966
#97 0x01124f90 in Fcall_interactively (function=53285562,
record_flag=53229594, keys=53250821) at callint.c:857
#98 0x01038124 in Ffuncall (nargs=4, args=0x88fb30) at eval.c:2973
#99 0x010375bf in call3 (fn=53415274, arg1=53285562, arg2=53229594,
arg3=53229594) at eval.c:2766
#100 0x010200d4 in Fcommand_execute (cmd=53285562,
record_flag=53229594, keys=53229594, special=53229594) at
keyboard.c:10276
#101 0x010063e6 in command_loop_1 () at keyboard.c:1573
#102 0x01033d86 in internal_condition_case (bfun=0x1005423
<command_loop_1>, handlers=53287322, hfun=0x1004c4d <cmd_error>) at
eval.c:1491
#103 0x01005089 in command_loop_2 (ignore=53229594) at keyboard.c:1157
#104 0x01033746 in internal_catch (tag=53285346, func=0x1005066
<command_loop_2>, arg=53229594) at eval.c:1248
#105 0x01005041 in command_loop () at keyboard.c:1136
#106 0x0100460b in recursive_edit_1 () at keyboard.c:756
#107 0x0100492d in Frecursive_edit () at keyboard.c:820
#108 0x010027a3 in main (argc=4, argv=0x9b2d00) at emacs.c:1706

Lisp Backtrace:
"byte-code" (0x88dc50)
"icomplete-exhibit" (0x88e0c8)
"run-hooks" (0x88e174)
0x3414ee0 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" (0x88f894)
"call-interactively" (0x88fb34)
(gdb)

---- Second backtrace ----

(gdb) run -Q -f icomplete-mode
Starting program: C:\Devel\emacs\repo\debug\src/..\bin\emacs.exe -Q -f
icomplete-mode
[New Thread 5276.0x14d8]
[New Thread 5276.0x153c]
[New Thread 5276.0x1774]
gdb: unknown target exception 0xc0000029 at 0x76f407b6

Program received signal ?, Unknown signal.
[Switching to Thread 5276.0x1774]
0x76f407b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
(gdb) bt
#0  0x76f407b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
#1  0x0088da00 in ?? ()
#2  0x74d207f0 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)
0x3414ee0 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" (0x88f894)
"call-interactively" (0x88fb34)
(gdb) thread 1
[Switching to thread 1 (Thread 5276.0x14d8)]#0  0x01054fbc in
Fcompare_strings (str1=58427441, start1=0, end1=0, str2=20087009,
start2=0, end2=0,
    ignore_case=53229618) at fns.c:272
272       i1_byte = string_char_to_byte (str1, i1);
(gdb) bt
#0  0x01054fbc in Fcompare_strings (str1=58427441, start1=0, end1=0,
str2=20087009, start2=0, end2=0, ignore_case=53229618) at fns.c:272
#1  0x01109d12 in Fall_completions (string=20087009,
collection=53215942, predicate=53229594, hide_spaces=53229594) at
minibuf.c:1571
#2  0x010381a3 in Ffuncall (nargs=4, args=0x88ba84) at eval.c:2977
#3  0x01125f61 in exec_byte_code (bytestr=20594801, vector=20594869,
maxdepth=48, args_template=4112, nargs=4, args=0x88bcf8) at
bytecode.c:785
#4  0x01038b30 in funcall_lambda (fun=20594773, nargs=4,
arg_vector=0x88bce8) at eval.c:3131
#5  0x0103844b in Ffuncall (nargs=5, args=0x88bce4) at eval.c:3015
#6  0x01125f61 in exec_byte_code (bytestr=20595697, vector=54431013,
maxdepth=24, args_template=0, nargs=0, args=0x88bf54) at
bytecode.c:785
#7  0x01038b30 in funcall_lambda (fun=54431237, nargs=0,
arg_vector=0x88bf54) at eval.c:3131
#8  0x0103844b in Ffuncall (nargs=1, args=0x88bf50) at eval.c:3015
#9  0x01035f11 in eval_sub (form=81860342) at eval.c:2286
#10 0x01033c7c in internal_lisp_condition_case (var=54339282,
bodyform=81860342, handlers=81860390) at eval.c:1445
#11 0x0112681c in exec_byte_code (bytestr=20595361, vector=20595541,
maxdepth=144, args_template=5136, nargs=4, args=0x88c434) at
bytecode.c:981
#12 0x01038b30 in funcall_lambda (fun=20595333, nargs=4,
arg_vector=0x88c424) at eval.c:3131
#13 0x0103844b in Ffuncall (nargs=5, args=0x88c420) at eval.c:3015
#14 0x01125f61 in exec_byte_code (bytestr=20595809, vector=20595861,
maxdepth=56, args_template=4112, nargs=4, args=0x88c6a8) at
bytecode.c:785
#15 0x01038b30 in funcall_lambda (fun=20595781, nargs=4,
arg_vector=0x88c698) at eval.c:3131
#16 0x0103844b in Ffuncall (nargs=5, args=0x88c694) at eval.c:3015
#17 0x01125f61 in exec_byte_code (bytestr=20579737, vector=54431589,
maxdepth=24, args_template=1028, nargs=1, args=0x88c8fc) at
bytecode.c:785
#18 0x01038b30 in funcall_lambda (fun=54430853, nargs=1,
arg_vector=0x88c8f8) at eval.c:3131
#19 0x0103844b in Ffuncall (nargs=2, args=0x88c8f4) at eval.c:3015
#20 0x01125f61 in exec_byte_code (bytestr=20575057, vector=54427781,
maxdepth=20, args_template=0, nargs=0, args=0x88cb64) at
bytecode.c:785
#21 0x01038b30 in funcall_lambda (fun=54429957, nargs=0,
arg_vector=0x88cb64) at eval.c:3131
#22 0x0103844b in Ffuncall (nargs=1, args=0x88cb60) at eval.c:3015
#23 0x01035f11 in eval_sub (form=81860198) at eval.c:2286
#24 0x01033c7c in internal_lisp_condition_case (var=54326370,
bodyform=81860198, handlers=81860246) at eval.c:1445
#25 0x0112681c in exec_byte_code (bytestr=20574881, vector=20574981,
maxdepth=60, args_template=2056, nargs=2, args=0x88cff0) at
bytecode.c:981
#26 0x01038b30 in funcall_lambda (fun=20574853, nargs=2,
arg_vector=0x88cfe8) at eval.c:3131
#27 0x0103844b in Ffuncall (nargs=3, args=0x88cfe4) at eval.c:3015
#28 0x01125f61 in exec_byte_code (bytestr=20579385, vector=20579685,
maxdepth=60, args_template=5136, nargs=5, args=0x88d278) at
bytecode.c:785
#29 0x01038b30 in funcall_lambda (fun=20579597, nargs=5,
arg_vector=0x88d264) at eval.c:3131
#30 0x0103844b in Ffuncall (nargs=6, args=0x88d260) at eval.c:3015
#31 0x01125f61 in exec_byte_code (bytestr=20581641, vector=20581789,
maxdepth=72, args_template=0, nargs=0, args=0x88d4e4) at
bytecode.c:785
#32 0x01038b30 in funcall_lambda (fun=20581613, nargs=0,
arg_vector=0x88d4e4) at eval.c:3131
#33 0x0103844b in Ffuncall (nargs=1, args=0x88d4e0) at eval.c:3015
#34 0x01125f61 in exec_byte_code (bytestr=58476945, vector=55233029,
maxdepth=36, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:785
#35 0x01038fb0 in funcall_lambda (fun=54608613, nargs=4,
arg_vector=0x88d754) at eval.c:3197
#36 0x0103844b in Ffuncall (nargs=5, args=0x88d750) at eval.c:3015
#37 0x01125f61 in exec_byte_code (bytestr=58476129, vector=59388421,
maxdepth=20, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:785
#38 0x01125512 in Fbyte_code (bytestr=58476129, vector=59388421,
maxdepth=20) at bytecode.c:423
#39 0x010361d0 in eval_sub (form=57801134) at eval.c:2320
#40 0x01033746 in internal_catch (tag=59394338, func=0x10357b2
<eval_sub>, arg=57801134) at eval.c:1248
#41 0x011267b5 in exec_byte_code (bytestr=58476241, vector=54611109,
maxdepth=8, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:966
#42 0x01125512 in Fbyte_code (bytestr=58476241, vector=54611109,
maxdepth=8) at bytecode.c:423
#43 0x010361d0 in eval_sub (form=57801070) at eval.c:2320
#44 0x01033c7c in internal_lisp_condition_case (var=53229594,
bodyform=57801070, handlers=57801166) at eval.c:1445
#45 0x0112681c in exec_byte_code (bytestr=58476497, vector=55180421,
maxdepth=28, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:981
#46 0x01038fb0 in funcall_lambda (fun=54610405, nargs=0,
arg_vector=0x88e0c8) at eval.c:3197
#47 0x0103844b in Ffuncall (nargs=1, args=0x88e0c4) at eval.c:3015
#48 0x01036faa in funcall_nil (nargs=1, args=0x88e0c4) at eval.c:2483
#49 0x01037413 in run_hook_with_args (nargs=1, args=0x88e0c4,
funcall=0x1036f92 <funcall_nil>) at eval.c:2672
#50 0x01036ff4 in Frun_hooks (nargs=1, args=0x88e174) at eval.c:2510
#51 0x01037db0 in Ffuncall (nargs=2, args=0x88e170) at eval.c:2948
#52 0x01125f61 in exec_byte_code (bytestr=58492129, vector=55213749,
maxdepth=8, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:785
#53 0x01038fb0 in funcall_lambda (fun=54611685, nargs=0,
arg_vector=0x88e3f4) at eval.c:3197
#54 0x0103844b in Ffuncall (nargs=1, args=0x88e3f0) at eval.c:3015
#55 0x01037511 in call0 (fn=54611685) at eval.c:2720
#56 0x010076f1 in safe_run_hooks_1 () at keyboard.c:1869
#57 0x01033d86 in internal_condition_case (bfun=0x1007674
<safe_run_hooks_1>, handlers=53229618, hfun=0x10076f3
<safe_run_hooks_error>)
    at eval.c:1491
#58 0x01007b1f in safe_run_hook_funcall (nargs=1, args=0x88e590) at
keyboard.c:1924
#59 0x01037413 in run_hook_with_args (nargs=1, args=0x88e590,
funcall=0x1007a65 <safe_run_hook_funcall>) at eval.c:2672
#60 0x01007b6e in safe_run_hooks (hook=54611685) at keyboard.c:1941
#61 0x01006425 in command_loop_1 () at keyboard.c:1587
#62 0x01033d86 in internal_condition_case (bfun=0x1005423
<command_loop_1>, handlers=53287322, hfun=0x1004c4d <cmd_error>) at
eval.c:1491
#63 0x01005089 in command_loop_2 (ignore=53229594) at keyboard.c:1157
#64 0x01033746 in internal_catch (tag=53400010, func=0x1005066
<command_loop_2>, arg=53229594) at eval.c:1248
#65 0x01004ff0 in command_loop () at keyboard.c:1122
#66 0x0100460b in recursive_edit_1 () at keyboard.c:756
#67 0x01106eb4 in read_minibuf (map=53697342, initial=53229594,
prompt=58407873, backup_n=53229594, expflag=0, histvar=53425754,
histpos=0,
    defalt=53229594, allow_props=0, inherit_input_method=0) at minibuf.c:673
#68 0x01107c07 in Fread_from_minibuffer (prompt=58407873,
initial_contents=53229594, keymap=53697342, sys_read=53229594,
hist=53229594,
    default_value=53229594, inherit_input_method=53229594) at minibuf.c:966
#69 0x0103835c in Ffuncall (nargs=8, args=0x88ea58) at eval.c:2992
#70 0x01125f61 in exec_byte_code (bytestr=20597785, vector=20597869,
maxdepth=72, args_template=8200, nargs=8, args=0x88ece4) at
bytecode.c:785
#71 0x01038b30 in funcall_lambda (fun=20597757, nargs=8,
arg_vector=0x88ecc4) at eval.c:3131
#72 0x0103844b in Ffuncall (nargs=9, args=0x88ecc0) at eval.c:3015
#73 0x01109fde in Fcompleting_read (prompt=58407873,
collection=53215942, predicate=53229594, require_match=53229594,
initial_input=53229594,
    hist=53229594, def=53229594, inherit_input_method=53229594) at
minibuf.c:1711
#74 0x01038403 in Ffuncall (nargs=3, args=0x88edd0) at eval.c:2999
#75 0x01125f61 in exec_byte_code (bytestr=20401153, vector=20401229,
maxdepth=32, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:785
#76 0x01038fb0 in funcall_lambda (fun=20401125, nargs=2,
arg_vector=0x88f034) at eval.c:3197
#77 0x0103844b in Ffuncall (nargs=3, args=0x88f030) at eval.c:3015
#78 0x01125f61 in exec_byte_code (bytestr=20401849, vector=20401941,
maxdepth=16, args_template=53229594, nargs=0, args=0x0) at
bytecode.c:785
#79 0x01038fb0 in funcall_lambda (fun=20401821, nargs=1,
arg_vector=0x88f1f0) at eval.c:3197
#80 0x01038780 in apply_lambda (fun=20401821, args=20396214) at eval.c:3074
#81 0x010364f2 in eval_sub (form=20396206) at eval.c:2359
#82 0x010357a1 in Feval (form=20396206, lexical=53229594) at eval.c:2168
#83 0x01123141 in Fcall_interactively (function=54284938,
record_flag=53229618, keys=53250821) at callint.c:346
#84 0x01038124 in Ffuncall (nargs=4, args=0x88f640) at eval.c:2973
#85 0x010375bf in call3 (fn=53415274, arg1=54284938, arg2=53229618,
arg3=53229594) at eval.c:2766
#86 0x010200d4 in Fcommand_execute (cmd=54284938,
record_flag=53229618, keys=53229594, special=53229594) at
keyboard.c:10276
#87 0x010203cf in Fexecute_extended_command (prefixarg=53229594) at
keyboard.c:10365
#88 0x01038044 in Ffuncall (nargs=2, args=0x88f890) at eval.c:2966
#89 0x01124f90 in Fcall_interactively (function=53285562,
record_flag=53229594, keys=53250821) at callint.c:857
#90 0x01038124 in Ffuncall (nargs=4, args=0x88fb30) at eval.c:2973
#91 0x010375bf in call3 (fn=53415274, arg1=53285562, arg2=53229594,
arg3=53229594) at eval.c:2766
#92 0x010200d4 in Fcommand_execute (cmd=53285562,
record_flag=53229594, keys=53229594, special=53229594) at
keyboard.c:10276
#93 0x010063e6 in command_loop_1 () at keyboard.c:1573
#94 0x01033d86 in internal_condition_case (bfun=0x1005423
<command_loop_1>, handlers=53287322, hfun=0x1004c4d <cmd_error>) at
eval.c:1491
#95 0x01005089 in command_loop_2 (ignore=53229594) at keyboard.c:1157
#96 0x01033746 in internal_catch (tag=53285346, func=0x1005066
<command_loop_2>, arg=53229594) at eval.c:1248
#97 0x01005041 in command_loop () at keyboard.c:1136
#98 0x0100460b in recursive_edit_1 () at keyboard.c:756
#99 0x0100492d in Frecursive_edit () at keyboard.c:820
#100 0x010027a3 in main (argc=4, argv=0xa22d00) at emacs.c:1706

Lisp Backtrace:
"byte-code" (0x88dc50)
"icomplete-exhibit" (0x88e0c8)
"run-hooks" (0x88e174)
0x3414ee0 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" (0x88f894)
"call-interactively" (0x88fb34)
(gdb)

Message #77 received at submit <at> debbugs.gnu.org (full text, mbox):

From: claudio.bley <at> gmail.com (Claudio Bley)
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sun, 01 Jan 2012 21:56:11 +0100

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

Message #80 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Claudio Bley <claudio.bley <at> gmail.com>
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sun, 1 Jan 2012 22:24:40 +0100

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

Curious, because I also use ido-mode and I've never had the crash when
invoking ido-find-file, just with the reported recipe.

    Juanma

Message #83 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: claudio.bley <at> gmail.com (Claudio Bley)
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sun, 01 Jan 2012 23:43:01 +0200

> From: claudio.bley <at> gmail.com (Claudio Bley)
> Date: Sun, 01 Jan 2012 21:56:11 +0100
> 
> 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.

Is the recipe just start "emacs -Q", type "M-x ido-mode RET", and then
"C-x C-f SOME-FILE RET"?  If so, it didn't crash for me when I tried
it now.

Message #86 received at submit <at> debbugs.gnu.org (full text, mbox):

From: claudio.bley <at> gmail.com (Claudio Bley)
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Mon, 02 Jan 2012 17:16:46 +0100

On 1 Jan 2012, Eli Zaretskii wrote:

>> From: claudio.bley <at> gmail.com (Claudio Bley)
>> Date: Sun, 01 Jan 2012 21:56:11 +0100
>>
>> 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.
>
> Is the recipe just start "emacs -Q", type "M-x ido-mode RET", and
> then "C-x C-f SOME-FILE RET"?

No. It is the same race condition as with icomplete.

The recipe is quite similar to what Juanma did:

1. emacs -Q

2. (require 'ido)
   (ido-mode t)
   (setq ido-enable-flex-matching t
         ido-max-directory-size 100000)

[I suppose the last options are not strictly necessary, but maybe it
 helps triggering the bug more frequently]

3. C-x C-f

4. type some random characters until there are no possible completions
of file names in the current directory (ido will start to
search for completions in other dirs)

5. as soon as the message "Searching for `whateveryoutyped`..."
appears, hit <backspace>.

6. go to step 4.

I can trigger the bug after at most 10 repetitions.

- Claudio

Message #89 received at submit <at> debbugs.gnu.org (full text, mbox):

From: claudio.bley <at> gmail.com (Claudio Bley)
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Wed, 04 Jan 2012 16:44:53 +0100

Hi.

Here's a simple example code exposing the crash:

----------------------------------------------------------------------

(defun dosmthg ()
  "`nth' is a bytecode function in bytecode.c
which sets immediate_quit to non-zero before execution."
  (let ((alist (cons 1 nil)))
    (setcdr alist alist)
    (nth most-positive-fixnum alist)))

(catch 'yahee
  (let ((throw-on-input 'yahee)
	(i 4))
    (sit-for 1)
    (while (> i 1)
      (message "hit a key after countdown... %d" (setq i (1- i)))
      (sit-for 1))
    (message "now!")
    (dosmthg)))

----------------------------------------------------------------------

Save as "triggerbug.el" and bytecompile.

Run "emacs -Q -l triggerbug.elc" and follow the on screen
instructions.

Message #92 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: claudio.bley <at> gmail.com (Claudio Bley)
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 06 Jan 2012 12:02:52 +0200

> From: claudio.bley <at> gmail.com (Claudio Bley)
> Date: Mon, 02 Jan 2012 17:16:46 +0100
> 
> On 1 Jan 2012, Eli Zaretskii wrote:
> 
> >> From: claudio.bley <at> gmail.com (Claudio Bley)
> >> Date: Sun, 01 Jan 2012 21:56:11 +0100
> >>
> >> 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.
> >
> > Is the recipe just start "emacs -Q", type "M-x ido-mode RET", and
> > then "C-x C-f SOME-FILE RET"?
> 
> No. It is the same race condition as with icomplete.
> 
> The recipe is quite similar to what Juanma did:
> 
> 1. emacs -Q
> 
> 2. (require 'ido)
>    (ido-mode t)
>    (setq ido-enable-flex-matching t
>          ido-max-directory-size 100000)
> 
> [I suppose the last options are not strictly necessary, but maybe it
>  helps triggering the bug more frequently]
> 
> 3. C-x C-f
> 
> 4. type some random characters until there are no possible completions
> of file names in the current directory (ido will start to
> search for completions in other dirs)
> 
> 5. as soon as the message "Searching for `whateveryoutyped`..."
> appears, hit <backspace>.
> 
> 6. go to step 4.

I cannot get it to display the "Searching for ..." message.  And I
cannot get it to crash.

Message #95 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Claudio Bley <claudio.bley <at> gmail.com>, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 6 Jan 2012 13:48:02 +0100

On Fri, Jan 6, 2012 at 11:02, Eli Zaretskii <eliz <at> gnu.org> wrote:

> I cannot get it to display the "Searching for ..." message.  And I
> cannot get it to crash.

Do you see the crash with the triggerbug.el recipe? It works (= crashes) for me.

    Juanma

Message #98 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Claudio Bley <claudio.bley <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
	9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 06 Jan 2012 14:19:09 +0100

> Do you see the crash with the triggerbug.el recipe? It works (= crashes) for me.

For me too.  Can't do much with the backtrace, though :-(

martin


(gdb) run
Starting program: c:/emacs/quickfixes/bin/emacs.exe
[New thread 212.0x11c]
[New thread 212.0x404]
[New thread 212.0x784]
[New thread 212.0x748]
[New thread 212.0x278]
[New thread 212.0x664]
[New thread 212.0x174]
[New thread 212.0x1d8]
[New thread 212.0x59c]
gdb: unknown target exception 0xc0000029 at 0x7c95eb28

Program received signal ?, Unknown signal.
[Switching to thread 212.0x404]
0x7c95eb28 in ntdll!RtlInsertElementGenericTableAvl ()
   from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0  0x7c95eb28 in ntdll!RtlInsertElementGenericTableAvl ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x77c05464 in msvcrt!_global_unwind2 ()
   from C:\WINDOWS\system32\msvcrt.dll
#2  0x77c06d8c in msvcrt!longjmp () from C:\WINDOWS\system32\msvcrt.dll
#3  0x0082ffe0 in ?? ()
#4  0x0101f938 in unwind_to_catch (catch=0x82ffe0, value=16906552)
    at eval.c:1323
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Lisp Backtrace:
"byte-code" (0x82e720)
"load" (0x82eef4)
"byte-compile-file" (0x82f0e0)
"let" (0x82f470)
"if" (0x82f600)
"let" (0x82f800)
"emacs-lisp-byte-compile-and-load-unconditionally" (0x82f994)
"call-interactively" (0x82fb94)
(gdb)

Message #101 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Claudio Bley <claudio.bley <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
	9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 6 Jan 2012 14:26:03 +0100

> For me too.  Can't do much with the backtrace, though :-(

It's a bit more informative if you switch to thread 1.

gdb: unknown target exception 0xc0000029 at 0x77b907b6

Program received signal ?, Unknown signal.
[Switching to Thread 3736.0x165c]
0x77b907b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
(gdb) bt
#0  0x77b907b6 in ntdll!EtwEventUnregister () from C:\Windows\system32\ntdll.dll
#1  0x0088e824 in ?? ()
#2  0x755907f0 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" (0x88eaf4)
"load" (0x88f254)
"command-line-1" (0x88f554)
"command-line" (0x88f888)
"normal-top-level" (0x88fae0)
(gdb) thread 1
[Switching to thread 1 (Thread 3736.0x143c)]
#0  0x010df77c in exec_byte_code (bytestr=59950785, vector=56834309,
maxdepth=12, args_template=54691866, nargs=0, args=0x0) at
bytecode.c:1016
1016                while (--op >= 0 && CONSP (v1))
(gdb) bt
#0  0x010df77c in exec_byte_code (bytestr=59950785, vector=56834309,
maxdepth=12, args_template=54691866, nargs=0, args=0x0) at
bytecode.c:1016
#1  0x01037b28 in funcall_lambda (fun=56833221, nargs=0,
arg_vector=0x342881a) at eval.c:3217
#2  0x0103700e in Ffuncall (nargs=1, args=0x88e500) at eval.c:3035
#3  0x010debea in exec_byte_code (bytestr=59950657, vector=60752517,
maxdepth=16, args_template=54691866, nargs=0, args=0x0) at
bytecode.c:785
#4  0x010de188 in Fbyte_code (bytestr=59950657, vector=60752517,
maxdepth=16) at bytecode.c:423
#5  0x01034e48 in eval_sub (form=59163478) at eval.c:2340
#6  0x010325fe in internal_catch (tag=60117186, func=0x103450f
<eval_sub>, arg=59163478) at eval.c:1256
#7  0x010df5a8 in exec_byte_code (bytestr=59950705, vector=60649957,
maxdepth=8, args_template=54691866, nargs=0, args=0x0) at
bytecode.c:966
#8  0x010de188 in Fbyte_code (bytestr=59950705, vector=60649957,
maxdepth=8) at bytecode.c:423
#9  0x01034e48 in eval_sub (form=59163430) at eval.c:2340
#10 0x01085897 in readevalloop (readcharfun=54774386,
stream=0x75602960, sourcename=59950849, printflag=0, unibyte=54691866,
readfun=54691866,
    start=54691866, end=54691866) at lread.c:1838
#11 0x010839ac in Fload (file=59961585, noerror=54691866,
nomessage=54691890, nosuffix=54691866, must_suffix=54691866) at
lread.c:1316
#12 0x01036dde in Ffuncall (nargs=4, args=0x88f250) at eval.c:3002
#13 0x010debea in exec_byte_code (bytestr=20300521, vector=20300933,
maxdepth=88, args_template=1028, nargs=1, args=0x88f558) at
bytecode.c:785
#14 0x010376f4 in funcall_lambda (fun=20300493, nargs=1,
arg_vector=0x404) at eval.c:3151
#15 0x0103700e in Ffuncall (nargs=2, args=0x88f550) at eval.c:3035
#16 0x010debea in exec_byte_code (bytestr=20284105, vector=20285029,
maxdepth=72, args_template=0, nargs=0, args=0x88f888) at
bytecode.c:785
#17 0x010376f4 in funcall_lambda (fun=20284077, nargs=0,
arg_vector=0x0) at eval.c:3151
#18 0x0103700e in Ffuncall (nargs=1, args=0x88f884) at eval.c:3035
#19 0x010debea in exec_byte_code (bytestr=20280297, vector=20280517,
maxdepth=32, args_template=0, nargs=0, args=0x88fae0) at
bytecode.c:785
#20 0x010376f4 in funcall_lambda (fun=20280269, nargs=0,
arg_vector=0x0) at eval.c:3151
#21 0x01037344 in apply_lambda (fun=20280269, args=54691866) at eval.c:3094
#22 0x010351a4 in eval_sub (form=54931686) at eval.c:2379
#23 0x010344fe in Feval (form=54931686, lexical=54691866) at eval.c:2188
#24 0x0100532a in top_level_2 () at keyboard.c:1168
#25 0x01032bdb in internal_condition_case (bfun=0x100530d
<top_level_2>, handlers=54749594, hfun=0x1004eba <cmd_error>) at
eval.c:1499
#26 0x0100535e in top_level_1 (ignore=54691866) at keyboard.c:1176
#27 0x010325fe in internal_catch (tag=54747618, func=0x100532c
<top_level_1>, arg=54691866) at eval.c:1256
#28 0x01005294 in command_loop () at keyboard.c:1131
#29 0x0100488f in recursive_edit_1 () at keyboard.c:758
#30 0x01004baa in Frecursive_edit () at keyboard.c:822
#31 0x010028b5 in main (argc=4, argv=0xb72d40) at emacs.c:1715

Lisp Backtrace:
"byte-code" (0x88eaf4)
"load" (0x88f254)
"command-line-1" (0x88f554)
"command-line" (0x88f888)
"normal-top-level" (0x88fae0)
(gdb)

Message #104 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: claudio.bley <at> gmail.com, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 06 Jan 2012 17:17:59 +0200

> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
> 	RCVD_IN_DNSWL_LOW,T_DKIM_INVALID autolearn=ham version=3.3.2
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 6 Jan 2012 13:48:02 +0100
> Cc: Claudio Bley <claudio.bley <at> gmail.com>, 9087 <at> debbugs.gnu.org
> 
> On Fri, Jan 6, 2012 at 11:02, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > I cannot get it to display the "Searching for ..." message.  And I
> > cannot get it to crash.
> 
> Do you see the crash with the triggerbug.el recipe?

No, I don't.

Message #107 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, Juanma Barranquero <lekktu <at> gmail.com>,
	9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 06 Jan 2012 17:07:18 +0100

>> Do you see the crash with the triggerbug.el recipe?
>
> No, I don't.

Try setting `debug-on-quit' to t.

martin

Message #110 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 06 Jan 2012 21:01:38 +0200

> Date: Fri, 06 Jan 2012 17:07:18 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Juanma Barranquero <lekktu <at> gmail.com>, claudio.bley <at> gmail.com, 
>  9087 <at> debbugs.gnu.org
> 
>  >> Do you see the crash with the triggerbug.el recipe?
>  >
>  > No, I don't.
> 
> Try setting `debug-on-quit' to t.

If you meant this:

  emacs -Q --eval "(setq debug-on-quit t)" -l triggerbug.el

then it doesn't help.

Message #113 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 06 Jan 2012 20:45:03 +0100

> If you meant this:
>
>   emacs -Q --eval "(setq debug-on-quit t)" -l triggerbug.el
>
> then it doesn't help.

I added

(setq debug-on-quit t)

to triggerbug.el, visit that file with emacs -Q, invoke
`emacs-lisp-byte-compile-and-load', and hit a key while I read "now!".

martin

Message #116 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 06 Jan 2012 21:53:17 +0200

> Date: Fri, 06 Jan 2012 20:45:03 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: lekktu <at> gmail.com, claudio.bley <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
>  > If you meant this:
>  >
>  >   emacs -Q --eval "(setq debug-on-quit t)" -l triggerbug.el
>  >
>  > then it doesn't help.
> 
> I added
> 
> (setq debug-on-quit t)
> 
> to triggerbug.el, visit that file with emacs -Q, invoke
> `emacs-lisp-byte-compile-and-load', and hit a key while I read "now!".

I see the reason why I couldn't reproduce this: it is only
reproducible with a byte-compiled triggerbug.elc.  I initially tried
with triggerbug.el.

Message #119 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rudalics <at> gmx.at, claudio.bley <at> gmail.com, lekktu <at> gmail.com
Cc: 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 06 Jan 2012 22:50:30 +0200

> Date: Fri, 06 Jan 2012 21:53:17 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
> > Date: Fri, 06 Jan 2012 20:45:03 +0100
> > From: martin rudalics <rudalics <at> gmx.at>
> > CC: lekktu <at> gmail.com, claudio.bley <at> gmail.com, 9087 <at> debbugs.gnu.org
> > 
> >  > If you meant this:
> >  >
> >  >   emacs -Q --eval "(setq debug-on-quit t)" -l triggerbug.el
> >  >
> >  > then it doesn't help.
> > 
> > I added
> > 
> > (setq debug-on-quit t)
> > 
> > to triggerbug.el, visit that file with emacs -Q, invoke
> > `emacs-lisp-byte-compile-and-load', and hit a key while I read "now!".
> 
> I see the reason why I couldn't reproduce this: it is only
> reproducible with a byte-compiled triggerbug.elc.  I initially tried
> with triggerbug.el.

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?  If not, what can we do to
make the throwing more "immediate"?

Claudio, can you see if this patch gives good results with
ido-find-file?

And why in the world isn't throw-on-input described in the ELisp
manual???


=== modified file 'src/w32fns.c'
--- src/w32fns.c	2012-01-05 09:46:05 +0000
+++ src/w32fns.c	2012-01-06 20:33:25 +0000
@@ -2479,6 +2479,7 @@ signal_user_input (void)
   if (!NILP (Vthrow_on_input))
     {
       Vquit_flag = Vthrow_on_input;
+#if 0
       /* If we're inside a function that wants immediate quits,
 	 do it now.  */
       if (immediate_quit && NILP (Vinhibit_quit))
@@ -2486,6 +2487,7 @@ signal_user_input (void)
 	  immediate_quit = 0;
 	  QUIT;
 	}
+#endif
     }
 }
 

Message #122 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, rudalics <at> gmx.at, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 6 Jan 2012 23:34:50 +0100

On Fri, Jan 6, 2012 at 21:50, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Claudio, can you see if this patch gives good results with
> ido-find-file?

It certainly fixes the original problem with completion of fonts.

    Juanma

Message #125 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, rudalics <at> gmx.at, 9087 <at> debbugs.gnu.org,
	lekktu <at> gmail.com
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Fri, 06 Jan 2012 19:42:24 -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?
If not, how comes it doesn't suffer from the same problem (or does it?)?


        Stefan

Message #128 received at 9087 <at> debbugs.gnu.org (full text, mbox):

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

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: rudalics <at> gmx.at,  claudio.bley <at> gmail.com,  lekktu <at> gmail.com,  9087 <at> debbugs.gnu.org
> Date: Fri, 06 Jan 2012 19:42:24 -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.  The only difference between
handling of throw-on-input and C-g on Windows is that the latter can
also interrupt prolonged system calls.  But throw-on-input is not
supposed to do that, right?  And we are not in a system call in this
case, we are just in a long calculation done by byte code.

Jason, could you please chime in?  signal_user_input was written by
you.  Doing a QUIT from a thread other than the Lisp evaluation thread
is clearly not TRT, I think, so it must be taken out.  The question
is: is there some way we can honor immediate_quit here, or should we
just ignore it?  TIA.

(Once again, why isn't throw-on-input documented?  With only a short
doc string lacking any details, I have no way of knowing what exactly
its contract is.)

Message #131 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 11:10:48 +0100

> 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?  If not, what can we do to
> make the throwing more "immediate"?

Could you shortly explain the possible consequences of applying this
patch and why the crash doesn't happen in non-compiled code (I'm too
lazy to figure these out by myself).

Thanks, martin

Message #134 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org,
	Stefan Monnier <monnier <at> iro.umontreal.ca>, Jason Rumney <jasonr <at> gnu.org>
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 11:11:57 +0100

>> Is a C-g also delayed in a similar way under w32?
>
> Yes, it is, at least in this case.

Can you please explain what this means?  If C-g is delayed does it mean
that I can't use it to quit immediately?  Or does it mean that I can
crash Emacs via C-g in a similar way as with the OP's scenario?

Why and how is all this handled differently on GNU systems?

Thanks, martin

Message #137 received at 9087 <at> debbugs.gnu.org (full text, mbox):

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

> Date: Sat, 07 Jan 2012 11:11:57 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Stefan Monnier <monnier <at> iro.umontreal.ca>, 
>  Jason Rumney <jasonr <at> gnu.org>,
>  claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
>  >> Is a C-g also delayed in a similar way under w32?
>  >
>  > Yes, it is, at least in this case.
> 
> Can you please explain what this means?  If C-g is delayed does it mean
> that I can't use it to quit immediately?  Or does it mean that I can
> crash Emacs via C-g in a similar way as with the OP's scenario?

The former, of course.  You can verify yourself that, in Emacs without
the patch I sent, typing C-g when triggerbug.el says "now!" does not
cause a crash, but a "Quit", albeit a slightly (by 1-2 seconds on my
box) delayed one.

> Why and how is all this handled differently on GNU systems?

On Posix hosts, Emacs reads keyboard input in the main thread, where
it is possible to do a throw to top level without wreaking havoc on
the stack.  In some configurations, keyboard input is actually handled
in a signal handler, and then the throw is even faster, because it
interrupts any on-going operation.

On Windows, there's a separate thread that reads messages posted by
Windows to the Emacs windows.  Throwing to top level from a different
thread is a no-no.  With my patch, throwing will be deferred until the
main thread is done with whatever it is doing, and gets to reading
input.

Message #140 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 12:58:34 +0200

> Date: Sat, 07 Jan 2012 11:10:48 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
>  > 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?  If not, what can we do to
>  > make the throwing more "immediate"?
> 
> Could you shortly explain the possible consequences of applying this
> patch

1. The crash is avoided. ;-)
2. The Emacs reaction to input event under throw-on-input is delayed
   until Emacs actually tries to read input.

(It is possible that 2. is actually what needs to happen in this case;
I don't know because the exact effects of throw-on-input are not
documented anywhere I could find.)

> and why the crash doesn't happen in non-compiled code

To trigger the crash, immediate_quit should be non-zero, because only
then would signal_user_input do a QUIT.  immediate_quit is set
non-zero by `nth' only when we run byte code that calls it (see
bytecode.c around line 1007); the function Fnth, called by
non-compiled Lisp code, does not do that.

The choice of `nth' is just one possibility to trigger this; you can
do it in any code that calls some primitive which sets immediate_quit
non-zero.

Message #143 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org,
	monnier <at> iro.umontreal.ca, jasonr <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 12:51:57 +0100

> You can verify yourself that, in Emacs without
> the patch I sent, typing C-g when triggerbug.el says "now!" does not
> cause a crash, but a "Quit", albeit a slightly (by 1-2 seconds on my
> box) delayed one.

Because `signal' resets immediate_quit to zero?

martin

Message #146 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 12:52:09 +0100

> The choice of `nth' is just one possibility to trigger this; you can
> do it in any code that calls some primitive which sets immediate_quit
> non-zero.

Thanks for all these explanations.  A final question: I have to set
`debug-on-quit' or `debug-on-error' to trigger the crash.  How do these
enter here?

martin

Message #149 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 14:11:58 +0200

> Date: Sat, 07 Jan 2012 12:52:09 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
>  > The choice of `nth' is just one possibility to trigger this; you can
>  > do it in any code that calls some primitive which sets immediate_quit
>  > non-zero.
> 
> Thanks for all these explanations.  A final question: I have to set
> `debug-on-quit' or `debug-on-error' to trigger the crash.  How do these
> enter here?

No idea.  For me, it happened even without those.

What GCC version do you use, and does it make any difference to try in
an unoptimized build?

Message #152 received at 9087 <at> debbugs.gnu.org (full text, mbox):

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

> Date: Sat, 07 Jan 2012 12:51:57 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: monnier <at> iro.umontreal.ca, jasonr <at> gnu.org, claudio.bley <at> gmail.com, 
>  lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
>  > You can verify yourself that, in Emacs without
>  > the patch I sent, typing C-g when triggerbug.el says "now!" does not
>  > cause a crash, but a "Quit", albeit a slightly (by 1-2 seconds on my
>  > box) delayed one.
> 
> Because `signal' resets immediate_quit to zero?

You mean, as explanation of the delay?  No, I don't think so.  I think
Emacs simply doesn't see C-g until the lengthy calculation is over.

Message #155 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
	9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 14:12:50 +0100

martin rudalics <rudalics <at> gmx.at> writes:

>> You can verify yourself that, in Emacs without
>> the patch I sent, typing C-g when triggerbug.el says "now!" does not
>> cause a crash, but a "Quit", albeit a slightly (by 1-2 seconds on my
>> box) delayed one.
>
> Because `signal' resets immediate_quit to zero?

Bnth doesn't call QUIT (it relies on immediate_quit), unlike Fnth.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #158 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 14:55:49 +0100

>> Thanks for all these explanations.  A final question: I have to set
>> `debug-on-quit' or `debug-on-error' to trigger the crash.  How do these
>> enter here?
>
> No idea.  For me, it happened even without those.

Funny, but probably of no importance.

> What GCC version do you use, and does it make any difference to try in
> an unoptimized build?

I use gcc 3.4.5 always configured with --no-opt.

martin

Message #161 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org,
	monnier <at> iro.umontreal.ca, jasonr <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 14:57:31 +0100

>>  > You can verify yourself that, in Emacs without
>>  > the patch I sent, typing C-g when triggerbug.el says "now!" does not
>>  > cause a crash, but a "Quit", albeit a slightly (by 1-2 seconds on my
>>  > box) delayed one.
>>
>> Because `signal' resets immediate_quit to zero?
>
> You mean, as explanation of the delay?

No.  I meant as an explanation of the non-crash.

> No, I don't think so.  I think
> Emacs simply doesn't see C-g until the lengthy calculation is over.

Likely.  But where is C-g treated differently from other input?

martin

Message #164 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
	9087 <at> debbugs.gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 14:57:41 +0100

> Bnth doesn't call QUIT (it relies on immediate_quit), unlike Fnth.

I'm probably too silly.  Bnth crashes on almost any input but C-g.  Why
does it not crash with C-g?

martin

Message #167 received at 9087 <at> debbugs.gnu.org (full text, mbox):

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

> Date: Sat, 07 Jan 2012 14:57:31 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: monnier <at> iro.umontreal.ca, jasonr <at> gnu.org, claudio.bley <at> gmail.com, 
>  lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
>  >>  > You can verify yourself that, in Emacs without
>  >>  > the patch I sent, typing C-g when triggerbug.el says "now!" does not
>  >>  > cause a crash, but a "Quit", albeit a slightly (by 1-2 seconds on my
>  >>  > box) delayed one.
>  >>
>  >> Because `signal' resets immediate_quit to zero?
>  >
>  > You mean, as explanation of the delay?
> 
> No.  I meant as an explanation of the non-crash.
> 
>  > No, I don't think so.  I think
>  > Emacs simply doesn't see C-g until the lengthy calculation is over.
> 
> Likely.  But where is C-g treated differently from other input?

Here:

  static void
  post_character_message (HWND hwnd, UINT msg,
			  WPARAM wParam, LPARAM lParam,
			  DWORD modifiers)
  {
    W32Msg wmsg;

    wmsg.dwModifiers = modifiers;

    /* Detect quit_char and set quit-flag directly.  Note that we
       still need to post a message to ensure the main thread will be
       woken up if blocked in sys_select, but we do NOT want to post
       the quit_char message itself (because it will usually be as if
       the user had typed quit_char twice).  Instead, we post a dummy
       message that has no particular effect. */
    {
      int c = wParam;
      if (isalpha (c) && wmsg.dwModifiers == ctrl_modifier)
	c = make_ctrl_char (c) & 0377;
      if (c == quit_char
	  || (wmsg.dwModifiers == 0 &&
	      w32_quit_key && wParam == w32_quit_key))
	{
	  Vquit_flag = Qt;

	  /* The choice of message is somewhat arbitrary, as long as
	     the main thread handler just ignores it. */
	  msg = WM_NULL;

	  /* Interrupt any blocking system calls.  */
	  signal_quit ();

	  /* As a safety precaution, forcibly complete any deferred
	     messages.  This is a kludge, but I don't see any particularly
	     clean way to handle the situation where a deferred message is
	     "dropped" in the lisp thread, and will thus never be
	     completed, eg. by the user trying to activate the menubar
	     when the lisp thread is busy, and then typing C-g when the
	     menubar doesn't open promptly (with the result that the
	     menubar never responds at all because the deferred
	     WM_INITMENU message is never completed).  Another problem
	     situation is when the lisp thread calls SendMessage (to send
	     a window manager command) when a message has been deferred;
	     the lisp thread gets blocked indefinitely waiting for the
	     deferred message to be completed, which itself is waiting for
	     the lisp thread to respond.

	     Note that we don't want to block the input thread waiting for
	     a response from the lisp thread (although that would at least
	     solve the deadlock problem above), because we want to be able
	     to receive C-g to interrupt the lisp thread.  */
	  cancel_all_deferred_msgs ();
	}
      else
	signal_user_input ();
    }

    my_post_msg (&wmsg, hwnd, msg, wParam, lParam);
  }

And signal_user_input then does:

  static void
  signal_user_input (void)
  {
    /* Interrupt any lisp that wants to be interrupted by input.  */
    if (!NILP (Vthrow_on_input))
      {
	Vquit_flag = Vthrow_on_input;
	/* If we're inside a function that wants immediate quits,
	   do it now.  */
	if (immediate_quit && NILP (Vinhibit_quit))
	  {
	    immediate_quit = 0;
	    QUIT;
	  }
      }
  }

This call to QUIT is the problem, because this code runs in a
different thread than the main Lisp thread, the one that set up the
setjmp point to which we longjmp when we throw to top level.  So it
unwinds the wrong stack.

By contrast, C-g does not call signal_user_input to be called, see
above.  So it avoids this fate.

Message #170 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org,
	schwab <at> linux-m68k.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 17:00:14 +0200

> Date: Sat, 07 Jan 2012 14:57:41 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Eli Zaretskii <eliz <at> gnu.org>, claudio.bley <at> gmail.com, 
>  lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
>  > Bnth doesn't call QUIT (it relies on immediate_quit), unlike Fnth.
> 
> I'm probably too silly.  Bnth crashes on almost any input but C-g.  Why
> does it not crash with C-g?

Because C-g is treated specially by the w32 thread that reads input,
see my other message with the details.

Message #173 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org,
	monnier <at> iro.umontreal.ca, jasonr <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 17:27:45 +0100

> This call to QUIT is the problem, because this code runs in a
> different thread than the main Lisp thread, the one that set up the
> setjmp point to which we longjmp when we throw to top level.  So it
> unwinds the wrong stack.

Thanks.  I'm beginning to understand.  Is post_character_message the
only potential source of this problem or are there others as well?

> By contrast, C-g does not call signal_user_input to be called, see
> above.  So it avoids this fate.

Naively asked: Could we avoid the problem if on normal input we did not
call signal_user_input but did something similar to C-g handling?

martin

Message #176 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org,
	monnier <at> iro.umontreal.ca, jasonr <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 19:05:41 +0200

> Date: Sat, 07 Jan 2012 17:27:45 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: monnier <at> iro.umontreal.ca, jasonr <at> gnu.org, claudio.bley <at> gmail.com, 
>  lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
>  > This call to QUIT is the problem, because this code runs in a
>  > different thread than the main Lisp thread, the one that set up the
>  > setjmp point to which we longjmp when we throw to top level.  So it
>  > unwinds the wrong stack.
> 
> Thanks.  I'm beginning to understand.  Is post_character_message the
> only potential source of this problem or are there others as well?

There are others.  Search for the callers of signal_user_input, and
you will find them.  E.g., it is called for mouse inputs as well.

>  > By contrast, C-g does not call signal_user_input to be called, see
>  > above.  So it avoids this fate.
> 
> Naively asked: Could we avoid the problem if on normal input we did not
> call signal_user_input but did something similar to C-g handling?

We could, but why would we want to?  signal_user_input does TRT,
except when immediate_quit is set.  If we don't call it, we won't be
able to support throw-on-input and while-no-input.

Message #179 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org,
	monnier <at> iro.umontreal.ca, jasonr <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 18:17:10 +0100

>> Thanks.  I'm beginning to understand.  Is post_character_message the
>> only potential source of this problem or are there others as well?
>
> There are others.  Search for the callers of signal_user_input, and
> you will find them.  E.g., it is called for mouse inputs as well.

I asked because I noticed these calls.  And indeed it crashes on mouse
input as well.

>> Naively asked: Could we avoid the problem if on normal input we did not
>> call signal_user_input but did something similar to C-g handling?
>
> We could, but why would we want to?  signal_user_input does TRT,
> except when immediate_quit is set.  If we don't call it, we won't be
> able to support throw-on-input and while-no-input.

I meant do the same as C-g when immediate_quit is set.

martin

Message #182 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org,
	monnier <at> iro.umontreal.ca, jasonr <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 19:31:01 +0200

> Date: Sat, 07 Jan 2012 18:17:10 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: monnier <at> iro.umontreal.ca, jasonr <at> gnu.org, claudio.bley <at> gmail.com, 
>  lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
>  >> Naively asked: Could we avoid the problem if on normal input we did not
>  >> call signal_user_input but did something similar to C-g handling?
>  >
>  > We could, but why would we want to?  signal_user_input does TRT,
>  > except when immediate_quit is set.  If we don't call it, we won't be
>  > able to support throw-on-input and while-no-input.
> 
> I meant do the same as C-g when immediate_quit is set.

Details, please.  What exactly are you suggesting that we do instead
of calling signal_user_input?

Message #185 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org,
	monnier <at> iro.umontreal.ca, jasonr <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 18:45:28 +0100

> Details, please.  What exactly are you suggesting that we do instead
> of calling signal_user_input?

When immediate_quit is set proceed in signal_user_input as if we
processed C-g in post_character_message.  Is that too naive?

martin

Message #188 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org,
	monnier <at> iro.umontreal.ca, jasonr <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 19:52:36 +0200

> Date: Sat, 07 Jan 2012 18:45:28 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: monnier <at> iro.umontreal.ca, jasonr <at> gnu.org, claudio.bley <at> gmail.com, 
>  lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
> 
>  > Details, please.  What exactly are you suggesting that we do instead
>  > of calling signal_user_input?
> 
> When immediate_quit is set proceed in signal_user_input as if we
> processed C-g in post_character_message.

That means we will call signal_quit that interrupts system calls (not
relevant to this case) and "forcibly complete any deferred messages"
(whatever that means) by calling cancel_all_deferred_msgs, which again
is not relevant.  By contrast, Vquit_flag will _not_ be set to
Vthrow_on_input, which will break throw-on-input and while-no-input.

IOW, all we do when we see C-g is interrupt any system calls and
deliver the C-g character to the main thread.  We do nothing special
besides that, AFAICS.  I don't see how this could help the case in
point.

Message #191 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, rudalics <at> gmx.at, 9087 <at> debbugs.gnu.org,
	lekktu <at> gmail.com, Jason Rumney <jasonr <at> gnu.org>
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
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.

> (Once again, why isn't throw-on-input documented?

It's largely an implementation detail of while-no-input, used for
non-essential background computations (e.g. icomplete).


        Stefan

Message #194 received at 9087 <at> debbugs.gnu.org (full text, mbox):

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, 9087 <at> debbugs.gnu.org,
	lekktu <at> gmail.com, jasonr <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 20:59:53 +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.
> 
> > (Once again, why isn't throw-on-input documented?
> 
> It's largely an implementation detail of while-no-input, used for
> non-essential background computations (e.g. icomplete).

Is it (and while-no-input) supposed to stop prolonged Lisp
calculations without delay?  If so, how exactly does that work on X,
where (AFAIK) keyboard input is not interrupt-driven?

Message #197 received at 9087 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: claudio.bley <at> gmail.com, rudalics <at> gmx.at, 9087 <at> debbugs.gnu.org,
	lekktu <at> gmail.com, jasonr <at> gnu.org
Subject: Re: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sun, 08 Jan 2012 09:01:28 -0500

>> It's largely an implementation detail of while-no-input, used for
>> non-essential background computations (e.g. icomplete).
> Is it (and while-no-input) supposed to stop prolonged Lisp
> calculations without delay?

Yes, it is supposed to be similar to a C-g, tho a bit less urgent.

> If so, how exactly does that work on X, where (AFAIK) keyboard input
> is not interrupt-driven?

AFAIK it is interrupt driven (and with SYNC_INPUT the interrupt just
sets a flag which is then checked in QUIT).


        Stefan

Message #202 received at 9087-done <at> debbugs.gnu.org (full text, mbox):

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.

Previous Next

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