Re: Weird crash behaviour in emacs

[Tim Van Holder]

> I've been fiddling with the garbage collector and it could have
> introduce a subtle bug.  Of course it can also be a whole bunch of
> other things.  Do you remember when the problem started to
> happen ?
> Can you try to narrow down to a set of changes that might
> have introduced the problem ?

Quite a while ago IIRC, but I had X/GTK-related crashes (bad drawables
etc) for some time, so it's not easy to pinpoint where those stopped
and these started.

> Also looking at your gdb session:
> 
> (gdb) bt
> #0  abort () at /home/tim/gnu/emacs/src/emacs.c:417
> #1  0x0812bc2f in Fgarbage_collect () at 
> /home/tim/gnu/emacs/src/alloc.c:4334
> #2  0x08140b47 in Ffuncall (nargs=3, args=0xbfffdf60) at 
> /home/tim/gnu/emacs/src/eval.c:2664
> #3  0x081404c2 in run_hook_list_with_args 
> (funlist=1482815800, nargs=3, args=0xbfffdf60) at 
> (gdb) up
> #1  0x0812bc2f in Fgarbage_collect () at 
> /home/tim/gnu/emacs/src/alloc.c:4334
> 4334                stack_copy = (char *) xmalloc 
> (stack_copy_size = i);
> 
> I don't see how this line could directly jump to `abort'.
> The closest I can think of is the `abort' call in UNBLOCK_INPUT
> inside `xmalloc' but I don't see why `xmalloc' would be inlined.
>
> Is the value of `interrupt_input_blocked' smaller than 0 ?
>
> Could you try and recompile with less optimization
> to see if that gives us more info ?

I rebuilt emacs with -gstabs+3 instead of -g -O2.
It seems the standard debug info results in bad line numbers - the
call to abort is not related to xmalloc at all:

(gdb) bt
#0  abort () at /home/tim/gnu/emacs/src/emacs.c:417
#1  0x0816606f in Fgarbage_collect () at
/home/tim/gnu/emacs/src/alloc.c:4308
#2  0x0817ffcb in Ffuncall (nargs=3, args=0xbfffd920) at
/home/tim/gnu/emacs/src/eval.c:2664
#3  0x0817fdc3 in run_hook_list_with_args (funlist=1483136192, nargs=3,
args=0xbfffd920) at /home/tim/gnu/emacs/src/eval.c:2446
#4  0x0813014d in signal_before_change (start_int=1, end_int=7,
preserve_ptr=0xbfffda30) at /home/tim/gnu/emacs/src/insdel.c:2043
#5  0x0812fe74 in prepare_to_modify_buffer (start=1, end=7,
preserve_ptr=0xbfffda30) at /home/tim/gnu/emacs/src/insdel.c:1941
...
(gdb)up
#1  0x0816606f in Fgarbage_collect () at
/home/tim/gnu/emacs/src/alloc.c:4308
4308        abort ();
(gdb) l
4303      Lisp_Object total[8];
4304      int count = SPECPDL_INDEX ();
4305      EMACS_TIME t1, t2, t3;
4306
4307      if (abort_on_gc)
4308        abort ();
4309
4310      EMACS_GET_TIME (t1);
4311
4312      /* Can't GC if pure storage overflowed because we can't determine

Grepping the source yields two places where abort_on_gc is used;
one in editfns.c (format), one in print.c (prin1_to_string).
The original traceback has:

#1  0x0812bc2f in Fgarbage_collect () at
/home/tim/gnu/emacs/src/alloc.c:4334
#2  0x08140b47 in Ffuncall (nargs=3, args=0xbfffdf60) at
/home/tim/gnu/emacs/src/eval.c:2664
#3  0x081404c2 in run_hook_list_with_args (funlist=1482815800, nargs=3,
args=0xbfffdf60) at /home/tim/gnu/emacs/src/eval.c:2446
#4  0x08101551 in signal_before_change (start_int=1, end_int=7,
preserve_ptr=0xbfffe040) at /home/tim/gnu/emacs/src/insdel.c:2043
#5  0x08101334 in prepare_to_modify_buffer (start=1, end=7,
preserve_ptr=0xbfffe040) at /home/tim/gnu/emacs/src/insdel.c:1941
#6  0x08100cc7 in del_range_1 (from=1, to=7, prepare=1,
ret_string=405581476) at /home/tim/gnu/emacs/src/insdel.c:1674
#7  0x08100be8 in del_range (from=141453472, to=141453472) at
/home/tim/gnu/emacs/src/insdel.c:1648
#8  0x080f7f16 in Ferase_buffer () at /home/tim/gnu/emacs/src/buffer.c:1983
#9  0x0814fef9 in Fprin1_to_string (object=947069732, noescape=141453472) at
/home/tim/gnu/emacs/src/print.c:785

So it seems that this is some special-case scenario where the garbage
collector ends up being called in an 'abort on gc' section.