emacs-pretest-bug
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]