bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer

[martin rudalics <rudalics@gmx.at>]

 > 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