[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer
From: |
Stephen Berman |
Subject: |
bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer |
Date: |
Sat, 09 Jul 2011 13:57:41 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
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
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, Stephen Berman, 2011/07/05
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, martin rudalics, 2011/07/06
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, Stephen Berman, 2011/07/06
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, martin rudalics, 2011/07/07
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, Stephen Berman, 2011/07/07
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, martin rudalics, 2011/07/07
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, Stephen Berman, 2011/07/08
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, martin rudalics, 2011/07/09
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer,
Stephen Berman <=
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, martin rudalics, 2011/07/09
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, Stephen Berman, 2011/07/09
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, Stephen Berman, 2011/07/09
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, martin rudalics, 2011/07/10
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, Stephen Berman, 2011/07/10
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, martin rudalics, 2011/07/10
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, Stephen Berman, 2011/07/10
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, martin rudalics, 2011/07/11
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, Stephen Berman, 2011/07/11
- bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer, martin rudalics, 2011/07/12