[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Weird crash behaviour in emacs
From: |
Stefan Monnier |
Subject: |
Re: Weird crash behaviour in emacs |
Date: |
Thu, 17 Jul 2003 07:49:45 -0400 |
> I've had several instances in the past where CVS Emacs just crapped
> out, but in most cases it was not repeatable (although running a lot
> of deletions from dired often triggered it, as reported earlier this
> month by Wang Chunyu).
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 ?
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 ?
Stefan