From: Stephen Berman <stephen.berman@gmx.net>
To: martin rudalics <rudalics@gmx.at>
Cc: 9006@debbugs.gnu.org
Subject: bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer
Date: Sat, 09 Jul 2011 13:57:41 +0200 [thread overview]
Message-ID: <87r55zekei.fsf@escher.fritz.box> (raw)
In-Reply-To: <4E1814F7.4060002@gmx.at> (martin rudalics's message of "Sat, 09 Jul 2011 10:44:39 +0200")
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
next prev parent reply other threads:[~2011-07-09 11:57 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-05 23:20 bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer Stephen Berman
2011-07-06 9:25 ` martin rudalics
2011-07-06 19:19 ` Stephen Berman
2011-07-07 8:23 ` martin rudalics
2011-07-07 9:32 ` Stephen Berman
2011-07-07 15:47 ` martin rudalics
2011-07-08 23:03 ` Stephen Berman
2011-07-09 8:44 ` martin rudalics
2011-07-09 11:57 ` Stephen Berman [this message]
2011-07-09 13:01 ` martin rudalics
2011-07-09 16:27 ` Stephen Berman
2011-07-09 16:54 ` Stephen Berman
2011-07-10 8:59 ` martin rudalics
2011-07-10 10:25 ` Stephen Berman
2011-07-10 13:30 ` martin rudalics
2011-07-10 20:31 ` Stephen Berman
2011-07-11 19:14 ` martin rudalics
2011-07-11 20:04 ` Stephen Berman
2011-07-12 8:36 ` martin rudalics
2011-07-12 8:51 ` Stephen Berman
2011-07-13 6:53 ` Stephen Berman
2011-07-13 7:24 ` Eli Zaretskii
2011-07-13 8:00 ` Stephen Berman
2011-07-13 10:03 ` Eli Zaretskii
2011-07-13 11:40 ` Stephen Berman
2011-07-13 8:37 ` martin rudalics
2011-07-13 10:05 ` Eli Zaretskii
2011-07-13 11:54 ` martin rudalics
2011-07-13 12:20 ` Stephen Berman
2011-07-13 11:39 ` Stephen Berman
2011-07-14 8:35 ` martin rudalics
2011-07-15 21:05 ` Stephen Berman
2011-07-10 8:58 ` martin rudalics
2011-07-09 12:44 ` Stephen Berman
2011-07-09 13:01 ` martin rudalics
2011-07-09 17:31 ` Eli Zaretskii
2011-07-10 8:59 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r55zekei.fsf@escher.fritz.box \
--to=stephen.berman@gmx.net \
--cc=9006@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.