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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

killing indirect buffer clobbers Emacs


From: Dave Love
Subject: killing indirect buffer clobbers Emacs
Date: Sun, 02 Jan 2005 17:26:26 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.2 (gnu/linux)

I've several times got Emacs into an unusable state when working with
my multi-mode.el, which uses indirect buffers.  As far as I can tell,
it's due to killing an indirect buffer which then doesn't seem to get
properly GC'd.  I get "marker does not point anywhere" from
(apparently) any command, each of which seems to be triggering GC.  I
can't then save buffers or kill Emacs.

Here's a backtrace after killing the indirect buffer in a session
which had recently created it and not done anything but move around in
it.  This wasn't with -q, though.

#0  Fsignal (error_symbol=137629265, data=0) at eval.c:1501
#1  0x0817f17f in error (m=0x81d0040 "Marker does not point anywhere",
    a1=0x8340e51 "", a2=0x8340e51 "", a3=0x8340e51 "") at eval.c:1812
#2  0x081412e6 in marker_position (marker=142840210) at marker.c:801
#3  0x08135b1a in set_buffer_internal_1 (b=0x883f268) at buffer.c:1803
#4  0x08167213 in truncate_undo_list (b=0x883f268) at undo.c:325
#5  0x0816ac75 in Fgarbage_collect () at alloc.c:4687
#6  0x081806e7 in Ffuncall (nargs=2, args=0xbfffee40) at eval.c:2715
#7  0x081801c0 in call1 (fn=137653025, arg1=137626505) at eval.c:2569
#8  0x0811f0bc in safe_run_hooks_1 (hook=-1073746288) at keyboard.c:2037
#9  0x0817e7ee in internal_condition_case (bfun=0x811f0a0 <safe_run_hooks_1>,
    handlers=137568321, hfun=0x811f0c0 <safe_run_hooks_error>) at eval.c:1385
#10 0x0811f15b in safe_run_hooks (hook=137629265) at keyboard.c:2065
...

In frame 3, `b' has a name of nil but a filename from a buffer which
had an indirect buffer.  Its `base_buffer' isn't null, so I assume it
is the indirect buffer.  Emacs is actually running
Qecho_area_clear_hook, but I also saw the error from at least
post-command-hook.

This happened in a build from 2044-12-22 but not from one a couple of
weeks older.  I'm not sure whether they both had full updates of the C
code, though.  The current source doesn't fix it.  It's in a Gtk build
on x86 Debian testing, in the unlikely case that's relevant.




reply via email to

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