From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer Date: Sat, 09 Jul 2011 10:44:39 +0200 Message-ID: <4E1814F7.4060002@gmx.at> References: <877h7wxqjv.fsf@escher.fritz.box> <4E1429F3.1010305@gmx.at> <87oc17xlmu.fsf@escher.fritz.box> <4E156D17.8020804@gmx.at> <871uy2qvv6.fsf@escher.fritz.box> <4E15D520.4030809@gmx.at> <87mxgobcj6.fsf@escher.fritz.box> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1310201163 31470 80.91.229.12 (9 Jul 2011 08:46:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 9 Jul 2011 08:46:03 +0000 (UTC) Cc: 9006@debbugs.gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 09 10:45:36 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QfTAJ-0008GR-KO for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Jul 2011 10:45:31 +0200 Original-Received: from localhost ([::1]:33955 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfTAI-0000OR-BV for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Jul 2011 04:45:30 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfT9u-0000N4-Ti for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2011 04:45:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QfT9s-0006Od-NZ for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2011 04:45:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfT9s-0006Ny-BB for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2011 04:45:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QfT9r-0000N2-74; Sat, 09 Jul 2011 04:45:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Jul 2011 08:45:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9006-submit@debbugs.gnu.org id=B9006.13102010931394 (code B ref 9006); Sat, 09 Jul 2011 08:45:03 +0000 Original-Received: (at 9006) by debbugs.gnu.org; 9 Jul 2011 08:44:53 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QfT9g-0000MR-LK for submit@debbugs.gnu.org; Sat, 09 Jul 2011 04:44:53 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1QfT9d-0000MC-2z for 9006@debbugs.gnu.org; Sat, 09 Jul 2011 04:44:50 -0400 Original-Received: (qmail invoked by alias); 09 Jul 2011 08:44:42 -0000 Original-Received: from 62-47-36-119.adsl.highway.telekom.at (EHLO [62.47.36.119]) [62.47.36.119] by mail.gmx.net (mp006) with SMTP; 09 Jul 2011 10:44:42 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+EPxogoZSEywiL4AXkXlIrwU7us3L1cr1RyVzIC8 8zpfQ0uRHRGQFz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87mxgobcj6.fsf@escher.fritz.box> X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 09 Jul 2011 04:45:03 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:48318 Archived-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