Re: mark_object crash in 22.1 and latest CVS (as of tonight)

["Kalman Reti" <kalman.reti@gmail.com>]

On Nov 15, 2007 12:09 PM, Richard Stallman <rms@gnu.org> wrote:
>     I've done some more experiments; it occurred to me that if the marker in the
>     undo list was gc-marked already when we got to the special processing, then
>     it would be skipped.
>
> I looked to see what you mean, and I see that some elements do get
> removed from the undo list.  I hadn't remembered that -- sorry.
>
> Is this the special processing you mean?
>
>         /* If a buffer's undo list is Qt, that means that undo is
>            turned off in that buffer.  Calling truncate_undo_list on
>            Qt tends to return NULL, which effectively turns undo back on.
>            So don't call truncate_undo_list if undo_list is Qt.  */
>         if (! EQ (nextb->undo_list, Qt))
>           {
>           ...
>

Yes.

> If so, it is supposed to delete elements for markers
> that weren't already marked by GC.  And then it marks the undo
> list in the normal way.

I believe it works to do this if you move the undo_list before name.
Otherwise, everything on the list is already marked by the normal
"start at the name offset and mark until you've reached the buffer
struct size" mechanism.

>
> Does it look like that code failed to remove an element
> which was supposed to update a marker?

No, it looks like a marker in the list is already marked; this
marker gets turned into the Lisp_Misc_Free cell.

>
> Was the marker already corrupted (replaced with Lisp_Misc_Free)
> before the start of the loop?

I believe so.  I think the culprit is the free_marker call in Fset_match_data.
I think this because I added a checking routine which, given a marker, looped
over all the cells in all the undo lists of all the buffers to see if
that marker
was in the caar of one of them, calling a dummy routine (krabort, on which
I could set a breakpoint) if so.  I added a call to this checking routine in
free_misc, fired up my test case and almost immediately got a hit.  (The
backtrace below can't be the whole story, since this happens much earlier
than the crash.  A gdb session which is automatically capturing a
backtrace at this
point and continuing, so I can show you the latest stack trace before the
crash, has run overnight now without reaching the crash.  Presumably
there is some mechanism which removes the Lisp_Misc_Free cell created
here before the GC trips over it and that something else [much] later on
is causing that mechanism to fail to work in the runnup to the crash.)

The early stack trace is at the end of this message.  One thing that isn't
clear to me is exactly who is calling set-match-data with the reseat
argument set to evaporate inside of the shell-command function.  This is
happening somewhere inside of the shell-command function which my
code calls.

(gdb) where
#0  krabort () at alloc.c:3364
#1  0x08129319 in check_for_problem (marker=147919074) at alloc.c:3380
#2  0x0812934c in free_misc (misc=147919074) at alloc.c:3394
#3  0x0811c354 in Fset_match_data (list=146951973, reseat=137508953)
    at search.c:3057
#4  0x0813e252 in Ffuncall (nargs=3, args=0xbffea3f0) at eval.c:3027
#5  0x08161c84 in Fbyte_code (bytestr=136239067, vector=136239092, maxdepth=24)
    at bytecode.c:679
#6  0x0813d87e in Feval (form=136239053) at eval.c:2361
#7  0x0813b22f in Fprogn (args=136239045) at eval.c:450
#8  0x0813eb33 in unbind_to (count=25, value=137414769) at eval.c:3378
#9  0x08162361 in Fbyte_code (bytestr=136238739, vector=136238756, maxdepth=64)
    at bytecode.c:890
#10 0x0813e73a in funcall_lambda (fun=136238676, nargs=1,
    arg_vector=0xbffea6e4) at eval.c:3211
#11 0x0813e359 in Ffuncall (nargs=2, args=0xbffea6e0) at eval.c:3081
#12 0x08161c84 in Fbyte_code (bytestr=144608715, vector=144609972, maxdepth=64)
    at bytecode.c:679
#13 0x0813e73a in funcall_lambda (fun=144610268, nargs=5,
    arg_vector=0xbffea804) at eval.c:3211
#14 0x0813e359 in Ffuncall (nargs=6, args=0xbffea800) at eval.c:3081
#15 0x08161c84 in Fbyte_code (bytestr=144597347, vector=144598732, maxdepth=48)
    at bytecode.c:679
#16 0x0813e73a in funcall_lambda (fun=144598884, nargs=3,
    arg_vector=0xbffea924) at eval.c:3211
#17 0x0813e359 in Ffuncall (nargs=4, args=0xbffea920) at eval.c:3081
#18 0x08161c84 in Fbyte_code (bytestr=144645315, vector=144646532, maxdepth=56)
    at bytecode.c:679
#19 0x0813e73a in funcall_lambda (fun=144646748, nargs=3,
    arg_vector=0xbffea9e0) at eval.c:3211
#20 0x0813e486 in apply_lambda (fun=144646748, args=146894853, eval_flag=1)
    at eval.c:3135
#21 0x0813d9d3 in Feval (form=146896869) at eval.c:2415
#22 0x0813b359 in Fsetq (args=146896861) at eval.c:552
#23 0x0813d70a in Feval (form=146896853) at eval.c:2302
#24 0x0813d7dd in Feval (form=146896845) at eval.c:2340
#25 0x0813e23f in Ffuncall (nargs=2, args=0xbffead34) at eval.c:3024
#26 0x08161c84 in Fbyte_code (bytestr=136525275, vector=136525292, maxdepth=24)
    at bytecode.c:679
#27 0x0813e73a in funcall_lambda (fun=136525236, nargs=1,
    arg_vector=0xbffeae44) at eval.c:3211
#28 0x0813e359 in Ffuncall (nargs=2, args=0xbffeae40) at eval.c:3081
#29 0x08161c84 in Fbyte_code (bytestr=136525523, vector=136525540, maxdepth=24)
    at bytecode.c:679
#30 0x0813e73a in funcall_lambda (fun=136525484, nargs=1,
    arg_vector=0xbffeaf54) at eval.c:3211
#31 0x0813e359 in Ffuncall (nargs=2, args=0xbffeaf50) at eval.c:3081
#32 0x08161c84 in Fbyte_code (bytestr=136523723, vector=136523740, maxdepth=16)
    at bytecode.c:679
#33 0x0813e73a in funcall_lambda (fun=136523692, nargs=0,
    arg_vector=0xbffeb084) at eval.c:3211
#34 0x0813e359 in Ffuncall (nargs=1, args=0xbffeb080) at eval.c:3081
#35 0x0813df04 in apply1 (fn=137580545, arg=137414769) at eval.c:2765
#36 0x08139bcc in Fcall_interactively (function=137580545,
    record_flag=137414769, keys=137463044) at callint.c:385
#37 0x080edd6d in Fcommand_execute (cmd=137580545, record_flag=137414769,
    keys=137414769, special=137414769) at keyboard.c:10435
#38 0x080e3e99 in command_loop_1 () at keyboard.c:1939
#39 0x0813c6f2 in internal_condition_case (bfun=0x80e31a4 <command_loop_1>,
    handlers=137472161, hfun=0x80e2c70 <cmd_error>) at eval.c:1493
#40 0x080e2f42 in command_loop_2 () at keyboard.c:1396
#41 0x0813c263 in internal_catch (tag=137463729,
    func=0x80e2f24 <command_loop_2>, arg=137414769) at eval.c:1229
#42 0x080e2ed0 in command_loop () at keyboard.c:1375
#43 0x080e28f4 in recursive_edit_1 () at keyboard.c:984
#44 0x080e2a34 in Frecursive_edit () at keyboard.c:1046
#45 0x080e18c9 in main (argc=3, argv=0xbffeb834) at emacs.c:1777

Lisp Backtrace:
"set-match-data" (0xbffea3f4)
"byte-code" (0xbffea480)
"shell-command" (0xbffea6e4)
"diffs-between-depot-and-client-different-branches" (0xbffea804)
"diffs-between" (0xbffea924)
"changesets-between" (0xbffea9e0)
"setq" (0xbffeab68)
"length" (0xbffeac28)
"eval" (0xbffead38)
"eval-last-sexp-1" (0xbffeae44)
"eval-last-sexp" (0xbffeaf54)
"eval-print-last-sexp" (0xbffeb084)
"call-interactively" (0xbffeb230)
(gdb)