GNU bug report logs - #9006
24.0.50; Abort in unshow_buffer/kill-buffer

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 9006 <at> debbugs.gnu.org
Subject: bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer
Date: Sat, 09 Jul 2011 10:44:39 +0200

> I have a new datapoint: I updated Emacs from the trunk today and started
> a session under gdb about 9 hours ago, and just got an abort again.
> Both the triggering conditions and the backtrace (included below) are
> similar but not identical to the previous aborts; I assume the
> differences in the backtrace are due to your new window code, which had
> not been in my previous build.

Indeed.

> As for the triggering conditions: I was
> again in Gnus, reading but not editing an article, and had just clicked
> on a URL link in the article, which calls a special function I use for
> browse-url-browser-function, which calls completing-read, and when the
> prompt appeared in the minibuffer, I changed my mind and type C-g -- and
> Emacs aborted.  Prior to that, unlike the previous crashes, I had not
> been moving point rapidly around the buffer, nor was there heavy CPU
> activity.  Aside from these differences, it's curious that I've now
> gotten the abort three days in a row, although before today I hadn't
> updated in almost a month and have been using the same configuration
> since long before.

I think there are three problems with this.

> #1  0x080a71a7 in unshow_buffer (w=0x9a8e828)
>     at /data/steve/bzr/emacs/quickfixes/src/window.c:1801
>         buf = 218835381
>         b = 0xd0b29b0

This problem is certainly due to the fact that vertical_motion blindly
does

  if (XBUFFER (w->buffer) != current_buffer)
    {
      /* Set the window's buffer temporarily to the current buffer.  */
      old_buffer = w->buffer;
      XSETBUFFER (w->buffer, current_buffer);
    }

and probably should do at least something like

  if (XBUFFER (w->buffer) != current_buffer)
    {
      /* Set the window's buffer temporarily to the current buffer.  */
      old_buffer = w->buffer;
      XSETBUFFER (w->buffer, current_buffer);
      set_marker_both (w->pointm, buffer, BEG, BEG_BYTE);
    }

instead.  Could you try with such a change?

> Lisp Backtrace:
> "set-window-buffer" (0xbfff66d4)
> "set-window-buffer-start-and-point" (0xbfff6854)
> "byte-code" (0xbfff6964)
> "switch-to-prev-buffer" (0xbfff6c54)
> "replace-buffer-in-windows" (0xbfff6dec)

Allowing to kill a temporary buffer while it's shown in a window just to
calculate how far `vertical-motion' would go if the buffer were shown in
a window is asking for trouble.  The kill-buffer here must get caught in
a way such that the old_buffer saved by vertical_motion gets reinstalled
in the window before `kill-buffer' gets called.

> "kill-buffer" (0xbfff6eb4)
> "and" (0xbfff6fa8)
> "vertical-motion" (0xbfff7d24)

The third and root issue to the problem you observe is that apparently
`vertical-motion' has problems with looking up the image cache, which,
as a consequence, seems responsible for the sluggishness you observed.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.