bug#12402: 24.2.50; Crash switching to ibuffer

[Andy Moreton]

On Mon 10 Sep 2012, Eli Zaretskii wrote:

>> > Any chance of a repeatable recipe?

I've not seen this precise crash again on newer trunk revisions. I have
seen a GC-related abort appearing recently, such as this from r110025.
It seems to take a day or two of use for it to appear:

#1  0x01153656 in emacs_abort () at w32fns.c:7215
#2  0x010554e4 in sys_kill (pid=0x58c, sig=0x16) at w32proc.c:1433
#3  0x010014d8 in fatal_error_backtrace (sig=0x16, backtrace_limit=0x7fffffff) 
at emacs.c:332
#4  0x010434cf in die (msg=0x15210ac "assertion failed: !VECTOR_MARKED_P 
(ptr)", file=0x151f181 "alloc.c", line=0x169d) at alloc.c:6743
#5  0x010411a4 in mark_vectorlike (ptr=0x3867de0) at alloc.c:5789
#6  0x01041b04 in mark_object (arg=0x3867de5) at alloc.c:6050

...many mark_object and mark_vectorlike calls...

#7282 0x0103a877 in mark_interval (i=0x6, dummy=0x353381a) at alloc.c:1557
#7283 0x012df039 in traverse_intervals_noorder (tree=0x43520c4, 
function=0x103a827 <mark_interval>, arg=0x353381a) at intervals.c:245
#7284 0x0104198e in mark_object (arg=0x4352721) at alloc.c:5962
#7285 0x010411e4 in mark_vectorlike (ptr=0x3e0d400) at alloc.c:5799
#7286 0x010413f5 in mark_buffer (buffer=0x3e0d400) at alloc.c:5850
#7287 0x01041a0c in mark_object (arg=0x3e0d405) at alloc.c:6007
...
...many mark_object and mark_vectorlike calls...
...
#7554 0x01041c4f in mark_object (arg=0x35412ba) at alloc.c:6107
#7555 0x01042330 in mark_object (arg=0x435ae26) at alloc.c:6212
#7556 0x0103a877 in mark_interval (i=0x6, dummy=0x353381a) at alloc.c:1557
#7557 0x012df039 in traverse_intervals_noorder (tree=0x4361454, 
function=0x103a827 <mark_interval>, arg=0x353381a) at intervals.c:245
#7558 0x0104198e in mark_object (arg=0x4361151) at alloc.c:5962
#7559 0x010411e4 in mark_vectorlike (ptr=0x5134600) at alloc.c:5799
#7560 0x010413f5 in mark_buffer (buffer=0x5134600) at alloc.c:5850
...
#7717 0x010401d6 in Fgarbage_collect () at alloc.c:5481
#7718 0x01039574 in maybe_gc () at lisp.h:3627
#7719 0x01033d10 in eval_sub (form=0x365db6e) at eval.c:2065
#7720 0x01034a81 in eval_sub (form=0x365dace) at eval.c:2239
#7721 0x01034a81 in eval_sub (form=0x3df8b56) at eval.c:2239
#7722 0x0103041e in Fprogn (args=0x35b608e) at eval.c:376
...
#7773 0x01005582 in command_loop () at keyboard.c:1163
#7774 0x01004b2b in recursive_edit_1 () at keyboard.c:784
#7775 0x01004e58 in Frecursive_edit () at keyboard.c:848
#7776 0x01002b23 in main (argc=0x2, argv=0xa425b0) at emacs.c:1660

Lisp Backtrace:
"ibuffer-aif" (0x82d444)
"ibuffer-awhen" (0x82d544)
0x35d5f60 Lisp type 6
"ibuffer-included-in-filter-p-1" (0x82d9d8)
"ibuffer-included-in-filter-p" (0x82dcc8)
0x3cd1fe0 PVEC_COMPILED
"mapcar" (0x82e15c)
"ibuffer-included-in-filters-p" (0x82e458)
0x3bd6120 PVEC_COMPILED
"ibuffer-split-list" (0x82ea38)
"ibuffer-generate-filter-groups" (0x82ed38)
"ibuffer-redisplay-engine" (0x82f048)
"ibuffer-update" (0x82f348)
"byte-code" (0x82f5ac)
"ibuffer-auto-update-changed" (0x82fa44)

Is the GC really supposed to build such a deeply recursive call chain ?

    AndyM