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

[Stephen Berman <stephen.berman@gmx.net>]

On Sat, 09 Jul 2011 10:44:39 +0200 martin rudalics <rudalics@gmx.at> wrote:

> 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?

Sure; but since I haven't found a way to induce the abort at will,
failing to get a crash wouldn't be conclusive evidence that this fixes
the problem.  But I'll rebuild with it and report anything noteworthy.

>> 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.

Your analysis sounds reasonable to me, and if you or somebody else can
come up with a patch, I'll be happy to try it.

Steve Berman