From: martin rudalics <rudalics@gmx.at>
To: Stephen Berman <stephen.berman@gmx.net>
Cc: 9006@debbugs.gnu.org
Subject: bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer
Date: Sat, 09 Jul 2011 10:44:39 +0200 [thread overview]
Message-ID: <4E1814F7.4060002@gmx.at> (raw)
In-Reply-To: <87mxgobcj6.fsf@escher.fritz.box>
> 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
next prev parent reply other threads:[~2011-07-09 8:44 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 [this message]
2011-07-09 11:57 ` Stephen Berman
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=4E1814F7.4060002@gmx.at \
--to=rudalics@gmx.at \
--cc=9006@debbugs.gnu.org \
--cc=stephen.berman@gmx.net \
/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.