* Elusive assertion failure related to completion
@ 2009-08-31 1:02 Juanma Barranquero
2009-09-01 10:00 ` martin rudalics
0 siblings, 1 reply; 8+ messages in thread
From: Juanma Barranquero @ 2009-08-31 1:02 UTC (permalink / raw)
To: Emacs developers
This is a crash I can consistently get while completing function
names. I'm not yet filing a bug report because details are a bit
sketchy.
Basically, starting Emacs my init.el, I do
C-h f -functions
and I get an assertion failure:
eval.c:3428: Emacs fatal error: assertion failed: SYMBOLP(this_binding.symbol)
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Unfortunately, trimming init.el to detect what's triggering it is not
easy; just commenting code around makes the bug much harder to
reproduce (but it still happens).
I just stumbled upon the bug today, but I can consistently repeat it
all the way to 23.0.90; I haven't tested earlier versions. As the
backtraces below suggest, it is related to using icomplete; removing
it makes the bug disappear.
I've been trying to debug it, but the backtraces are not always
identical. One sample follows.
Juanma
gdb: unknown target exception 0xc0000029 at 0x7c9601cc
Program received signal ?, Unknown signal.
[Switching to thread 3668.0x718]
0x7c9601cc in ntdll!LdrFindEntryForAddress () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7c9601cc in ntdll!LdrFindEntryForAddress () from
C:\WINDOWS\system32\ntdll.dll
#1 0x0082e21c in ?? ()
#2 0x207ffe48 in ?? ()
#3 0x0082ffe0 in ?? ()
#4 0xc0000027 in ?? ()
#5 0x00000002 in ?? ()
#6 0x00000000 in ?? ()
Lisp Backtrace:
"byte-code" (0x82e510)
"icomplete-exhibit" (0x82e9f8)
"run-hooks" (0x82eaa4)
0x3040da4 PVEC_COMPILED
"run-hooks" (0x82eee4)
"completing-read" (0x82f4f0)
"setq" (0x82f668)
"let" (0x82f7f8)
"call-interactively" (0x82fafc)
(gdb) thread 1
[Switching to thread 1 (thread 3668.0x2f0)]#0 delete_all_subwindows
(w=0x33c0a00) at window.c:6314
6314 w->total_lines = w->buffer; /* See
Fset_window_configuration for excuse. */
(gdb) bt
#0 delete_all_subwindows (w=0x33c0a00) at window.c:6314
#1 0x011c099a in delete_all_subwindows (w=0x33c0000) at window.c:6308
#2 0x011bf523 in Fset_window_configuration (configuration=59128388)
at window.c:6105
#3 0x0103f82c in unbind_to (count=60, value=48252929) at eval.c:3401
#4 0x01193415 in Fall_completions (string=20048835,
collection=48254980, predicate=48317513, hide_spaces=48252929) at
minibuf.c:1693
#5 0x0103e191 in Ffuncall (nargs=4, args=0x82be10) at eval.c:3056
#6 0x011df86d in Fbyte_code (bytestr=20345539, vector=20345660,
maxdepth=40) at bytecode.c:678
#7 0x0103ecbd in funcall_lambda (fun=20345476, nargs=4,
arg_vector=0x82c138) at eval.c:3233
#8 0x0103e519 in Ffuncall (nargs=5, args=0x82c134) at eval.c:3092
#9 0x011df86d in Fbyte_code (bytestr=20346979, vector=20347036,
maxdepth=48) at bytecode.c:678
#10 0x0103c3c9 in Feval (form=20346965) at eval.c:2383
#11 0x0103a0da in internal_lisp_condition_case (var=48757169,
bodyform=20346965, handlers=20347077) at eval.c:1458
#12 0x011e0526 in Fbyte_code (bytestr=20346547, vector=20346764,
maxdepth=80) at bytecode.c:868
#13 0x0103ecbd in funcall_lambda (fun=20346468, nargs=4,
arg_vector=0x82c844) at eval.c:3233
#14 0x0103e519 in Ffuncall (nargs=5, args=0x82c840) at eval.c:3092
#15 0x011df86d in Fbyte_code (bytestr=20347315, vector=20347404,
maxdepth=48) at bytecode.c:678
#16 0x0103ecbd in funcall_lambda (fun=20347260, nargs=4,
arg_vector=0x82cb64) at eval.c:3233
#17 0x0103e519 in Ffuncall (nargs=5, args=0x82cb60) at eval.c:3092
#18 0x011df86d in Fbyte_code (bytestr=20333499, vector=20333556,
maxdepth=40) at bytecode.c:678
#19 0x0103ecbd in funcall_lambda (fun=20333468, nargs=1,
arg_vector=0x82ce84) at eval.c:3233
#20 0x0103e519 in Ffuncall (nargs=2, args=0x82ce80) at eval.c:3092
#21 0x011df86d in Fbyte_code (bytestr=20328795, vector=20328844,
maxdepth=24) at bytecode.c:678
#22 0x0103c3c9 in Feval (form=20328781) at eval.c:2383
#23 0x0103a0da in internal_lisp_condition_case (var=48757169,
bodyform=20328781, handlers=20328877) at eval.c:1458
#24 0x011e0526 in Fbyte_code (bytestr=20328683, vector=20328740,
maxdepth=24) at bytecode.c:868
#25 0x0103ecbd in funcall_lambda (fun=20328636, nargs=2,
arg_vector=0x82d564) at eval.c:3233
#26 0x0103e519 in Ffuncall (nargs=3, args=0x82d560) at eval.c:3092
#27 0x011df86d in Fbyte_code (bytestr=20333659, vector=20333716,
maxdepth=40) at bytecode.c:678
#28 0x0103ecbd in funcall_lambda (fun=20333596, nargs=4,
arg_vector=0x82d884) at eval.c:3233
#29 0x0103e519 in Ffuncall (nargs=5, args=0x82d880) at eval.c:3092
#30 0x011df86d in Fbyte_code (bytestr=20335099, vector=20335212,
maxdepth=56) at bytecode.c:678
#31 0x0103ecbd in funcall_lambda (fun=20335076, nargs=0,
arg_vector=0x82dba4) at eval.c:3233
#32 0x0103e519 in Ffuncall (nargs=1, args=0x82dba0) at eval.c:3092
#33 0x011df86d in Fbyte_code (bytestr=50133139, vector=56130308,
maxdepth=72) at bytecode.c:678
#34 0x0103ecbd in funcall_lambda (fun=50640196, nargs=4,
arg_vector=0x82ded4) at eval.c:3233
#35 0x0103e519 in Ffuncall (nargs=5, args=0x82ded0) at eval.c:3092
#36 0x011df86d in Fbyte_code (bytestr=50132915, vector=50233476,
maxdepth=40) at bytecode.c:678
#37 0x0103c3c9 in Feval (form=56006373) at eval.c:2383
#38 0x01039c2f in internal_catch (tag=55585033, func=0x103b98b
<Feval>, arg=56006373) at eval.c:1249
#39 0x011e0492 in Fbyte_code (bytestr=50226035, vector=50640036,
maxdepth=16) at bytecode.c:853
#40 0x0103c3c9 in Feval (form=56006605) at eval.c:2383
#41 0x0103a0da in internal_lisp_condition_case (var=48252929,
bodyform=56006605, handlers=56006229) at eval.c:1458
#42 0x011e0526 in Fbyte_code (bytestr=50227795, vector=55440516,
maxdepth=56) at bytecode.c:868
#43 0x0103ecbd in funcall_lambda (fun=50642660, nargs=0,
arg_vector=0x82e9f8) at eval.c:3233
#44 0x0103e519 in Ffuncall (nargs=1, args=0x82e9f4) at eval.c:3092
#45 0x0103d2b5 in run_hook_with_args (nargs=1, args=0x82e9f4,
cond=to_completion) at eval.c:2705
#46 0x0103cffa in Frun_hooks (nargs=1, args=0x82eaa4) at eval.c:2568
#47 0x0103dc44 in Ffuncall (nargs=2, args=0x82eaa0) at eval.c:3027
#48 0x011df86d in Fbyte_code (bytestr=52989251, vector=50204292,
maxdepth=16) at bytecode.c:678
#49 0x0103ecbd in funcall_lambda (fun=50597284, nargs=0,
arg_vector=0x82ee28) at eval.c:3233
#50 0x0103e519 in Ffuncall (nargs=1, args=0x82ee24) at eval.c:3092
#51 0x0103d2b5 in run_hook_with_args (nargs=1, args=0x82ee24,
cond=to_completion) at eval.c:2705
#52 0x0103cffa in Frun_hooks (nargs=1, args=0x82eee4) at eval.c:2568
#53 0x0103dc44 in Ffuncall (nargs=2, args=0x82eee0) at eval.c:3027
#54 0x0103d5b7 in call1 (fn=48423985, arg1=48304657) at eval.c:2827
#55 0x0100b9c6 in safe_run_hooks_1 (hook=2) at keyboard.c:2158
#56 0x0103a1d6 in internal_condition_case (bfun=0x100b992
<safe_run_hooks_1>, handlers=48252977, hfun=0x100b9d1
<safe_run_hooks_error>)
at eval.c:1513
#57 0x0100ba70 in safe_run_hooks (hook=48304657) at keyboard.c:2186
#58 0x0100a9d7 in command_loop_1 () at keyboard.c:1922
#59 0x0103a1d6 in internal_condition_case (bfun=0x100725a
<command_loop_1>, handlers=48316609, hfun=0x10069d0 <cmd_error>) at
eval.c:1513
#60 0x01006e69 in command_loop_2 () at keyboard.c:1359
#61 0x01039c2f in internal_catch (tag=48426657, func=0x1006e49
<command_loop_2>, arg=48252929) at eval.c:1249
#62 0x01006dd2 in command_loop () at keyboard.c:1324
#63 0x01006127 in recursive_edit_1 () at keyboard.c:953
#64 0x011903f2 in read_minibuf (map=48242149, initial=48252929,
prompt=60318691, backup_n=0, expflag=0, histvar=48480121, histpos=0,
defalt=20410179, allow_props=0, inherit_input_method=0) at minibuf.c:739
#65 0x01193769 in Fcompleting_read (prompt=60318691,
collection=48254980, predicate=48317513, require_match=48252977,
initial_input=48252929, hist=48252929, def=20410179,
inherit_input_method=48252929) at minibuf.c:1823
#66 0x0103c73d in Feval (form=52546973) at eval.c:2405
#67 0x01037f3d in Fsetq (args=52546965) at eval.c:552
#68 0x0103beb1 in Feval (form=52546957) at eval.c:2324
#69 0x01037d69 in Fprogn (args=52546717) at eval.c:450
#70 0x01039788 in Flet (args=52546949) at eval.c:1091
#71 0x0103beb1 in Feval (form=52546869) at eval.c:2324
#72 0x011e3152 in Fcall_interactively (function=49501401,
record_flag=48252929, keys=48286468) at callint.c:364
#73 0x0103e0f0 in Ffuncall (nargs=4, args=0x82faf8) at eval.c:3052
#74 0x0103d62d in call3 (fn=48450945, arg1=49501401, arg2=48252929,
arg3=48252929) at eval.c:2872
#75 0x01023f40 in Fcommand_execute (cmd=49501401,
record_flag=48252929, keys=48252929, special=48252929) at
keyboard.c:10530
#76 0x0100a977 in command_loop_1 () at keyboard.c:1903
#77 0x0103a1d6 in internal_condition_case (bfun=0x100725a
<command_loop_1>, handlers=48316609, hfun=0x10069d0 <cmd_error>) at
eval.c:1513
#78 0x01006e69 in command_loop_2 () at keyboard.c:1359
#79 0x01039c2f in internal_catch (tag=48312729, func=0x1006e49
<command_loop_2>, arg=48252929) at eval.c:1249
#80 0x01006e20 in command_loop () at keyboard.c:1338
#81 0x01006127 in recursive_edit_1 () at keyboard.c:953
#82 0x010065fc in Frecursive_edit () at keyboard.c:1015
#83 0x01002a8d in main (argc=1, argv=0xa92720) at emacs.c:1849
Lisp Backtrace:
"byte-code" (0x82e510)
"icomplete-exhibit" (0x82e9f8)
"run-hooks" (0x82eaa4)
0x3040da4 PVEC_COMPILED
"run-hooks" (0x82eee4)
"completing-read" (0x82f4f0)
"setq" (0x82f668)
"let" (0x82f7f8)
"call-interactively" (0x82fafc)
(gdb)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Elusive assertion failure related to completion
2009-08-31 1:02 Elusive assertion failure related to completion Juanma Barranquero
@ 2009-09-01 10:00 ` martin rudalics
2009-09-01 11:33 ` Juanma Barranquero
0 siblings, 1 reply; 8+ messages in thread
From: martin rudalics @ 2009-09-01 10:00 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Emacs developers
> I've been trying to debug it, but the backtraces are not always
> identical. One sample follows.
Does the following part show up in all backtraces?
> [Switching to thread 1 (thread 3668.0x2f0)]#0 delete_all_subwindows
> (w=0x33c0a00) at window.c:6314
> 6314 w->total_lines = w->buffer; /* See
> Fset_window_configuration for excuse. */
If so, does the bug trigger the same way when you replace that
w->total_lines = w->buffer; /* See Fset_window_configuration for excuse. */
line by something like
if (BUFFERP (w->buffer))
w->total_lines = w->buffer; /* See Fset_window_configuration for excuse. */
which is just a wild guess, though.
martin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Elusive assertion failure related to completion
2009-09-01 10:00 ` martin rudalics
@ 2009-09-01 11:33 ` Juanma Barranquero
2009-09-01 17:25 ` martin rudalics
0 siblings, 1 reply; 8+ messages in thread
From: Juanma Barranquero @ 2009-09-01 11:33 UTC (permalink / raw)
To: martin rudalics; +Cc: Emacs developers
On Tue, Sep 1, 2009 at 12:00, martin rudalics<rudalics@gmx.at> wrote:
> Does the following part show up in all backtraces?
No, alas.
> If so, does the bug trigger the same way when you replace that
> which is just a wild guess, though.
Yes, it still triggers.
I'm including another backtrace (this one is with your patch, BTW).
Juanma
Breakpoint 1, w32_abort () at w32fns.c:7344
7344 button = MessageBox (NULL,
(gdb) bt
#0 w32_abort () at w32fns.c:7344
#1 0x0111f10e in Fset_window_configuration (configuration=59573636)
at window.c:6278
#2 0x01018acb in unbind_to (count=320, value=48257025) at eval.c:3401
#3 0x01019326 in unwind_to_catch (catch=0x82eefc, value=<value
optimized out>) at eval.c:1294
#4 0x0101ae42 in Fthrow (tag=57206457, value=48257073) at eval.c:1336
#5 0x011fa518 in signal_user_input () at w32fns.c:2680
#6 0x011fa578 in post_character_message (hwnd=0x1d04c8, msg=258,
wParam=99, lParam=3014657, modifiers=0) at w32fns.c:2744
#7 0x011fbe0a in w32_wnd_proc@0 (hwnd=0x1d04c8, msg=258, wParam=99,
lParam=3014657) at w32fns.c:3120
#8 0x7e398734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
#9 0x001d04c8 in ?? ()
#10 0x00000102 in ?? ()
#11 0x00000063 in ?? ()
#12 0x002e0001 in ?? ()
#13 0x011faf09 in w32_msg_pump (msg_buf=0x7f) at w32fns.c:2492
#14 0x7e398816 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
#15 0x011faf09 in w32_msg_pump (msg_buf=0xdcbaabcd) at w32fns.c:2492
#16 0x7e3989cd in USER32!GetWindowLongW () from C:\WINDOWS\system32\user32.dll
#17 0x00000000 in ?? ()
Lisp Backtrace:
"all-completions" (0x82e094)
"completion-pcm--all-completions" (0x82e1d8)
"byte-code" (0x82e280)
"completion-pcm--find-all-completions" (0x82e4d4)
"completion-pcm-all-completions" (0x82e614)
0x125afb4 PVEC_COMPILED
"byte-code" (0x82e7f0)
"completion--some" (0x82ea24)
"completion-all-completions" (0x82eb64)
"completion-all-sorted-completions" (0x82eca4)
"icomplete-completions" (0x82edf4)
"byte-code" (0x82eea0)
"byte-code" (0x82f020)
"icomplete-exhibit" (0x82f29c)
"run-hooks" (0x82f334)
0x30c6284 PVEC_COMPILED
"run-hooks" (0x82f534)
"completing-read" (0x82f910)
"setq" (0x82f9e4)
"let" (0x82fac4)
"call-interactively" (0x82fc8c)
(gdb) thread 1
[Switching to thread 1 (thread 3004.0x8b8)]#0 0x6c616e72 in ?? ()
(gdb) bt
#0 0x6c616e72 in ?? ()
#1 0x01018acb in unbind_to (count=320, value=48257025) at eval.c:3401
#2 0x01019326 in unwind_to_catch (catch=0x82f558, value=<value
optimized out>) at eval.c:1294
#3 0x0101a94c in Fsignal (error_symbol=48321137, data=48257025) at eval.c:1727
#4 0x0101a9a2 in xsignal (error_symbol=48321137, data=48257025) at eval.c:1752
#5 0x0101b3e5 in xsignal0 (error_symbol=48321137) at eval.c:1762
#6 0x0118ab94 in text_read_only (propval=55873536) at textprop.c:93
#7 0x0118add7 in verify_interval_modification (buf=0x355c600,
start=1, end=24) at textprop.c:2219
#8 0x0116bd44 in prepare_to_modify_buffer (start=1, end=24,
preserve_ptr=0x82def0) at insdel.c:2056
#9 0x0116ef37 in del_range_1 (from=55873536, to=24, prepare=1,
ret_string=0) at insdel.c:1806
#10 0x0116ef81 in del_range (from=1, to=24) at insdel.c:1781
#11 0x010794dd in Ferase_buffer () at buffer.c:2126
#12 0x011094bb in read_minibuf_unwind (data=48257025) at minibuf.c:944
#13 0x01018acb in unbind_to (count=960, value=48257025) at eval.c:3401
#14 0x01109b58 in Fall_completions (string=18961955, collection=<value
optimized out>, predicate=48321609, hide_spaces=48257025)
at minibuf.c:1693
#15 0x0101a3d8 in Ffuncall (nargs=4, args=0x82e090) at eval.c:3056
#16 0x0113bd32 in Fbyte_code (bytestr=19259259, vector=19259380,
maxdepth=<value optimized out>) at bytecode.c:678
#17 0x0101c8fe in funcall_lambda (fun=19259196, nargs=4,
arg_vector=0x82e1d8) at eval.c:3233
#18 0x0101a033 in Ffuncall (nargs=5, args=0x82e1d4) at eval.c:3092
#19 0x0113bd32 in Fbyte_code (bytestr=19260699, vector=19260756,
maxdepth=<value optimized out>) at bytecode.c:678
#20 0x0101c2a0 in Feval (form=19260685) at eval.c:2383
#21 0x0101d17a in internal_lisp_condition_case (var=48761337,
bodyform=19260685, handlers=19260797) at eval.c:1458
#22 0x0113c5d2 in Fbyte_code (bytestr=19260267, vector=19260484,
maxdepth=<value optimized out>) at bytecode.c:868
#23 0x0101c8fe in funcall_lambda (fun=19260188, nargs=4,
arg_vector=0x82e4d4) at eval.c:3233
#24 0x0101a033 in Ffuncall (nargs=5, args=0x82e4d0) at eval.c:3092
#25 0x0113bd32 in Fbyte_code (bytestr=19261035, vector=19261124,
maxdepth=<value optimized out>) at bytecode.c:678
#26 0x0101c8fe in funcall_lambda (fun=19260980, nargs=4,
arg_vector=0x82e614) at eval.c:3233
#27 0x0101a033 in Ffuncall (nargs=5, args=0x82e610) at eval.c:3092
#28 0x0113bd32 in Fbyte_code (bytestr=19247059, vector=19247116,
maxdepth=<value optimized out>) at bytecode.c:678
#29 0x0101c8fe in funcall_lambda (fun=19247028, nargs=1,
arg_vector=0x82e754) at eval.c:3233
#30 0x0101a033 in Ffuncall (nargs=2, args=0x82e750) at eval.c:3092
#31 0x0113bd32 in Fbyte_code (bytestr=19242323, vector=19242372,
maxdepth=<value optimized out>) at bytecode.c:678
#32 0x0101c2a0 in Feval (form=19242309) at eval.c:2383
#33 0x0101d17a in internal_lisp_condition_case (var=48761337,
bodyform=19242309, handlers=19242405) at eval.c:1458
#34 0x0113c5d2 in Fbyte_code (bytestr=19242211, vector=19242268,
maxdepth=<value optimized out>) at bytecode.c:868
#35 0x0101c8fe in funcall_lambda (fun=19242164, nargs=2,
arg_vector=0x82ea24) at eval.c:3233
#36 0x0101a033 in Ffuncall (nargs=3, args=0x82ea20) at eval.c:3092
#37 0x0113bd32 in Fbyte_code (bytestr=19247219, vector=19247276,
maxdepth=<value optimized out>) at bytecode.c:678
#38 0x0101c8fe in funcall_lambda (fun=19247156, nargs=4,
arg_vector=0x82eb64) at eval.c:3233
#39 0x0101a033 in Ffuncall (nargs=5, args=0x82eb60) at eval.c:3092
#40 0x0113bd32 in Fbyte_code (bytestr=19248659, vector=19248772,
maxdepth=<value optimized out>) at bytecode.c:678
#41 0x0101c8fe in funcall_lambda (fun=19248636, nargs=0,
arg_vector=0x82eca4) at eval.c:3233
#42 0x0101a033 in Ffuncall (nargs=1, args=0x82eca0) at eval.c:3092
#43 0x0113bd32 in Fbyte_code (bytestr=57133155, vector=56392196,
maxdepth=<value optimized out>) at bytecode.c:678
#44 0x0101c8fe in funcall_lambda (fun=51147172, nargs=4,
arg_vector=0x82edf4) at eval.c:3233
#45 0x0101a033 in Ffuncall (nargs=5, args=0x82edf0) at eval.c:3092
#46 0x0113bd32 in Fbyte_code (bytestr=57133971, vector=57128388,
maxdepth=<value optimized out>) at bytecode.c:678
#47 0x0101c2a0 in Feval (form=56331557) at eval.c:2383
#48 0x01019850 in internal_catch (tag=57206457, func=0x101bc5f
<Feval>, arg=56331557) at eval.c:1249
#49 0x0113c618 in Fbyte_code (bytestr=57134115, vector=51143012,
maxdepth=<value optimized out>) at bytecode.c:853
#50 0x0101c2a0 in Feval (form=56331493) at eval.c:2383
#51 0x0101d17a in internal_lisp_condition_case (var=48257025,
bodyform=56331493, handlers=56331589) at eval.c:1458
#52 0x0113c5d2 in Fbyte_code (bytestr=57134387, vector=57176580,
maxdepth=<value optimized out>) at bytecode.c:868
#53 0x0101c8fe in funcall_lambda (fun=51146852, nargs=0,
arg_vector=0x82f29c) at eval.c:3233
#54 0x0101a033 in Ffuncall (nargs=1, args=0x82f298) at eval.c:3092
#55 0x0101b788 in run_hook_with_args (nargs=1, args=0x82f298,
cond=to_completion) at eval.c:2705
#56 0x0101b8ff in Frun_hooks (nargs=1, args=0x82f334) at eval.c:2568
#57 0x0101a24a in Ffuncall (nargs=2, args=0x82f330) at eval.c:3027
#58 0x0113bd32 in Fbyte_code (bytestr=57134675, vector=54102484,
maxdepth=<value optimized out>) at bytecode.c:678
#59 0x0101c8fe in funcall_lambda (fun=51143300, nargs=0,
arg_vector=0x82f49c) at eval.c:3233
#60 0x0101a033 in Ffuncall (nargs=1, args=0x82f498) at eval.c:3092
#61 0x0101b788 in run_hook_with_args (nargs=1, args=0x82f498,
cond=to_completion) at eval.c:2705
#62 0x0101b8ff in Frun_hooks (nargs=1, args=0x82f534) at eval.c:2568
#63 0x0101a24a in Ffuncall (nargs=2, args=0x82f530) at eval.c:3027
#64 0x0101b635 in call1 (fn=48428081, arg1=48308753) at eval.c:2827
#65 0x0108406b in safe_run_hooks_1 (hook=8582504) at keyboard.c:2158
#66 0x010197a6 in internal_condition_case (bfun=0x1084046
<safe_run_hooks_1>, handlers=48257073, hfun=0x108d416
<safe_run_hooks_error>)
at eval.c:1513
#67 0x0108d3d2 in safe_run_hooks (hook=48308753) at keyboard.c:2186
#68 0x01097251 in command_loop_1 () at keyboard.c:1922
#69 0x010197a6 in internal_condition_case (bfun=0x1096c2e
<command_loop_1>, handlers=48320705, hfun=0x108df81 <cmd_error>) at
eval.c:1513
#70 0x0108d40c in command_loop_2 () at keyboard.c:1359
#71 0x01019850 in internal_catch (tag=48430753, func=0x108d3e9
<command_loop_2>, arg=48257025) at eval.c:1249
#72 0x0108dd6b in command_loop () at keyboard.c:1324
#73 0x0108e119 in recursive_edit_1 () at keyboard.c:953
#74 0x0110b986 in read_minibuf (map=48246245, initial=48257025,
prompt=<value optimized out>, backup_n=0, expflag=0, histvar=48484217,
histpos=0, defalt=48257025, allow_props=0, inherit_input_method=0)
at minibuf.c:739
#75 0x0110c337 in Fcompleting_read (prompt=55945907,
collection=48259076, predicate=48321609, require_match=48257073,
initial_input=48257025, hist=48257025, def=48257025,
inherit_input_method=48257025) at minibuf.c:1823
#76 0x0101c13c in Feval (form=52317925) at eval.c:2405
#77 0x0101c633 in Fsetq (args=52317917) at eval.c:552
#78 0x0101c0d5 in Feval (form=52317909) at eval.c:2324
#79 0x0101c75e in Fprogn (args=55873536) at eval.c:450
#80 0x0101d3f4 in Flet (args=52317901) at eval.c:1091
#81 0x0101c0d5 in Feval (form=52317797) at eval.c:2324
#82 0x0113d898 in Fcall_interactively (function=49597753,
record_flag=48257025, keys=48290564) at callint.c:364
#83 0x0101a441 in Ffuncall (nargs=4, args=0x82fc88) at eval.c:3052
#84 0x0101a6c3 in call3 (fn=48455041, arg1=49597753, arg2=48257025,
arg3=48257025) at eval.c:2872
#85 0x01097206 in command_loop_1 () at keyboard.c:1903
#86 0x010197a6 in internal_condition_case (bfun=0x1096c2e
<command_loop_1>, handlers=48320705, hfun=0x108df81 <cmd_error>) at
eval.c:1513
#87 0x0108d40c in command_loop_2 () at keyboard.c:1359
#88 0x01019850 in internal_catch (tag=48316825, func=0x108d3e9
<command_loop_2>, arg=48257025) at eval.c:1249
#89 0x0108ddc2 in command_loop () at keyboard.c:1338
#90 0x0108e119 in recursive_edit_1 () at keyboard.c:953
#91 0x0108e285 in Frecursive_edit () at keyboard.c:1015
#92 0x01003021 in main (argc=1, argv=0xa92728) at emacs.c:1849
Lisp Backtrace:
"all-completions" (0x82e094)
"completion-pcm--all-completions" (0x82e1d8)
"byte-code" (0x82e280)
"completion-pcm--find-all-completions" (0x82e4d4)
"completion-pcm-all-completions" (0x82e614)
0x125afb4 PVEC_COMPILED
"byte-code" (0x82e7f0)
"completion--some" (0x82ea24)
"completion-all-completions" (0x82eb64)
"completion-all-sorted-completions" (0x82eca4)
"icomplete-completions" (0x82edf4)
"byte-code" (0x82eea0)
"byte-code" (0x82f020)
"icomplete-exhibit" (0x82f29c)
"run-hooks" (0x82f334)
0x30c6284 PVEC_COMPILED
"run-hooks" (0x82f534)
"completing-read" (0x82f910)
"setq" (0x82f9e4)
"let" (0x82fac4)
"call-interactively" (0x82fc8c)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Elusive assertion failure related to completion
2009-09-01 11:33 ` Juanma Barranquero
@ 2009-09-01 17:25 ` martin rudalics
2009-09-01 21:23 ` Juanma Barranquero
0 siblings, 1 reply; 8+ messages in thread
From: martin rudalics @ 2009-09-01 17:25 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Emacs developers
> #1 0x0111f10e in Fset_window_configuration (configuration=59573636)
> at window.c:6278
Could you check if it's triggerd by the xassert
xassert (NILP (leaf_windows[i]->hchild)
&& NILP (leaf_windows[i]->vchild));
in window.c round line 6271? The most simple approach would be to take
this out temporarily.
martin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Elusive assertion failure related to completion
2009-09-01 17:25 ` martin rudalics
@ 2009-09-01 21:23 ` Juanma Barranquero
2009-09-01 23:32 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Juanma Barranquero @ 2009-09-01 21:23 UTC (permalink / raw)
To: martin rudalics; +Cc: Emacs developers
On Tue, Sep 1, 2009 at 19:25, martin rudalics<rudalics@gmx.at> wrote:
> Could you check if it's triggerd by the xassert
>
> xassert (NILP (leaf_windows[i]->hchild)
> && NILP (leaf_windows[i]->vchild));
No, it's not :-(
I think the assertion failure is a read herring; it seems like some
kind of memory corruption. In fact, sometimes I just get a crash in
other unrelated places.
The only thing really constant is the Lisp backtrace, with the error
always happening after calling `icomplete-exhibit'.
Juanma
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Elusive assertion failure related to completion
2009-09-01 21:23 ` Juanma Barranquero
@ 2009-09-01 23:32 ` Stefan Monnier
2009-09-02 9:59 ` David Kastrup
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2009-09-01 23:32 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: martin rudalics, Emacs developers
>> Could you check if it's triggerd by the xassert
>>
>> xassert (NILP (leaf_windows[i]->hchild)
>> && NILP (leaf_windows[i]->vchild));
> No, it's not :-(
> I think the assertion failure is a read herring; it seems like some
> kind of memory corruption. In fact, sometimes I just get a crash in
> other unrelated places.
Yes, looking at the code, I can't think of a way this data could be
anything else than a symbol at that point, so it smells like
memory corruption.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Elusive assertion failure related to completion
2009-09-01 23:32 ` Stefan Monnier
@ 2009-09-02 9:59 ` David Kastrup
2009-09-02 19:35 ` Juanma Barranquero
0 siblings, 1 reply; 8+ messages in thread
From: David Kastrup @ 2009-09-02 9:59 UTC (permalink / raw)
To: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Could you check if it's triggerd by the xassert
>>>
>>> xassert (NILP (leaf_windows[i]->hchild)
>>> && NILP (leaf_windows[i]->vchild));
>
>> No, it's not :-(
>
>> I think the assertion failure is a read herring; it seems like some
>> kind of memory corruption. In fact, sometimes I just get a crash in
>> other unrelated places.
>
> Yes, looking at the code, I can't think of a way this data could be
> anything else than a symbol at that point, so it smells like
> memory corruption.
Concerning "at that point", let me quote from DEBUG:
** When you are trying to analyze failed assertions, it will be
essential to compile Emacs either completely without optimizations or
at least (when using GCC) with the -fno-crossjumping option. Failure
to do so may make the compiler recycle the same abort call for all
assertions in a given function, rendering the stack backtrace useless
for identifying the specific failed assertion.
--
David Kastrup
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Elusive assertion failure related to completion
2009-09-02 9:59 ` David Kastrup
@ 2009-09-02 19:35 ` Juanma Barranquero
0 siblings, 0 replies; 8+ messages in thread
From: Juanma Barranquero @ 2009-09-02 19:35 UTC (permalink / raw)
To: David Kastrup; +Cc: emacs-devel
On Wed, Sep 2, 2009 at 11:59, David Kastrup<dak@gnu.org> wrote:
> Concerning "at that point", let me quote from DEBUG:
>
> ** When you are trying to analyze failed assertions, it will be
> essential to compile Emacs either completely without optimizations or
> at least (when using GCC) with the -fno-crossjumping option. Failure
> to do so may make the compiler recycle the same abort call for all
> assertions in a given function, rendering the stack backtrace useless
> for identifying the specific failed assertion.
Let me quote you from the Emacs binary used to report the error that
started this thread:
system-configuration-options is a variable defined in `C source code'.
Its value is
"--with-gcc (4.3) --no-opt --cflags -DENABLE_CHECKING=1
-DSITELOAD_PURESIZE_EXTRA=200000 -DXASSERTS=1 -IC:/emacs/build/include
-fno-crossjumping"
Juanma
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-09-02 19:35 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-31 1:02 Elusive assertion failure related to completion Juanma Barranquero
2009-09-01 10:00 ` martin rudalics
2009-09-01 11:33 ` Juanma Barranquero
2009-09-01 17:25 ` martin rudalics
2009-09-01 21:23 ` Juanma Barranquero
2009-09-01 23:32 ` Stefan Monnier
2009-09-02 9:59 ` David Kastrup
2009-09-02 19:35 ` Juanma Barranquero
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).