From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer Date: Sat, 09 Jul 2011 13:57:41 +0200 Message-ID: <87r55zekei.fsf@escher.fritz.box> 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> <4E1814F7.4060002@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1310212709 21988 80.91.229.12 (9 Jul 2011 11:58:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 9 Jul 2011 11:58:29 +0000 (UTC) Cc: 9006@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 09 13:58:25 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 1QfWAz-0000w7-KV for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Jul 2011 13:58:25 +0200 Original-Received: from localhost ([::1]:40802 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfWAy-0002t2-Rp for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Jul 2011 07:58:24 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfWAf-0002sa-Sm for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2011 07:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QfWAd-0006O6-RZ for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2011 07:58:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfWAd-0006O0-Jn for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2011 07:58:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QfWAc-0005T7-F6; Sat, 09 Jul 2011 07:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman 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 11:58:02 +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.131021267221005 (code B ref 9006); Sat, 09 Jul 2011 11:58:02 +0000 Original-Received: (at 9006) by debbugs.gnu.org; 9 Jul 2011 11:57:52 +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 1QfWAR-0005Sk-RV for submit@debbugs.gnu.org; Sat, 09 Jul 2011 07:57:52 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1QfWAP-0005SY-IH for 9006@debbugs.gnu.org; Sat, 09 Jul 2011 07:57:50 -0400 Original-Received: (qmail invoked by alias); 09 Jul 2011 11:57:42 -0000 Original-Received: from i59F56261.versanet.de (EHLO escher.home) [89.245.98.97] by mail.gmx.net (mp006) with SMTP; 09 Jul 2011 13:57:42 +0200 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX18oP0cEDaAoAxo7AZoYbCDipfOd1uQB/2SwtAjpsP 1ZKSvnxjlH7DQZ Original-Received: by escher.home (Postfix, from userid 1000) id 75F745F912; Sat, 9 Jul 2011 13:57:41 +0200 (CEST) In-Reply-To: <4E1814F7.4060002@gmx.at> (martin rudalics's message of "Sat, 09 Jul 2011 10:44:39 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) 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 07:58:02 -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:48327 Archived-At: On Sat, 09 Jul 2011 10:44:39 +0200 martin rudalics 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