From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#7728: 24.0.50; GDB backtrace from abort Date: Sun, 09 Jan 2011 23:18:14 +0200 Message-ID: <83ei8lkc89.fsf@gnu.org> References: <30041A5C411E45A7B7AF7A9ECA3AA0BE@us.oracle.com> <83y67echvm.fsf@gnu.org> <837heopknq.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1294608264 16968 80.91.229.12 (9 Jan 2011 21:24:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 9 Jan 2011 21:24:24 +0000 (UTC) Cc: 7728@debbugs.gnu.org To: monnier@iro.umontreal.ca, cyd@stupidchicken.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 09 22:24:19 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pc2kJ-0004C2-Jj for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Jan 2011 22:24:15 +0100 Original-Received: from localhost ([127.0.0.1]:50987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pc2kJ-0005H1-0b for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Jan 2011 16:24:15 -0500 Original-Received: from [140.186.70.92] (port=39204 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pc2kA-0005Gw-Qh for bug-gnu-emacs@gnu.org; Sun, 09 Jan 2011 16:24:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pc2k9-0000TU-4f for bug-gnu-emacs@gnu.org; Sun, 09 Jan 2011 16:24:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pc2k9-0000TP-0M for bug-gnu-emacs@gnu.org; Sun, 09 Jan 2011 16:24:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Pc2XW-0005HL-Ki; Sun, 09 Jan 2011 16:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Jan 2011 21:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7728 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7728-submit@debbugs.gnu.org id=B7728.129460746020283 (code B ref 7728); Sun, 09 Jan 2011 21:11:02 +0000 Original-Received: (at 7728) by debbugs.gnu.org; 9 Jan 2011 21:11:00 +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 1Pc2XU-0005H5-4Y for submit@debbugs.gnu.org; Sun, 09 Jan 2011 16:11:00 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Pc2XR-0005Gq-AC for 7728@debbugs.gnu.org; Sun, 09 Jan 2011 16:10:58 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LER00A00XT91200@a-mtaout23.012.net.il> for 7728@debbugs.gnu.org; Sun, 09 Jan 2011 23:18:16 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.131.253]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LER009ROXUCMA80@a-mtaout23.012.net.il>; Sun, 09 Jan 2011 23:18:14 +0200 (IST) In-reply-to: <837heopknq.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 09 Jan 2011 16:11:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:43230 Archived-At: Ping! This is a bug that I think we should fix for Emacs 23.3. > Date: Sat, 01 Jan 2011 20:02:17 +0200 > From: Eli Zaretskii > Cc: 7728@debbugs.gnu.org > > > From: Stefan Monnier > > Cc: Drew Adams , 7728@debbugs.gnu.org > > Date: Sat, 25 Dec 2010 15:35:31 -0500 > > > > If selected_window is nil because of Fset_window_configuration, then it > > is presumably nil for all the intervening and some of the subsequent > > code, and I suspect fixing it earlier in the call chain will be > > preferable: e.g., it doesn't make sense to "display_and_set_cursor" in > > the "selected_window = nil" case. > > After some looking around, I'm sorry to report that I don't see how to > do that. Here are the details: > > We set selected_window to nil as a semi-kludgey way of preventing > select-window from storing in the old selected window the value of > point of the buffer that has been restored into that window. > select-window has this code: > > sf = SELECTED_FRAME (); > if (XFRAME (WINDOW_FRAME (w)) != sf) > { > XFRAME (WINDOW_FRAME (w))->selected_window = window; > /* Use this rather than Fhandle_switch_frame > so that FRAME_FOCUS_FRAME is moved appropriately as we > move around in the state where a minibuffer in a separate > frame is active. */ > Fselect_frame (WINDOW_FRAME (w), norecord); > /* Fselect_frame called us back so we've done all the work already. */ > eassert (EQ (window, selected_window)); > return window; > } > else > sf->selected_window = window; > > /* Store the current buffer's actual point into the > old selected window. It belongs to that window, > and when the window is not selected, must be in the window. */ > if (!NILP (selected_window)) > { > ow = XWINDOW (selected_window); > if (! NILP (ow->buffer)) > set_marker_both (ow->pointm, ow->buffer, > BUF_PT (XBUFFER (ow->buffer)), > BUF_PT_BYTE (XBUFFER (ow->buffer))); > } > > selected_window = window; > > The last `if' clause is what we want to bypass, when we restore window > configuration as the last part of save-window-excursion. Note that > select-window stores the right value into selected_window right after > that, but the call to Fselect_frame that crashes happens before that, > so selected_window is still nil. > > Now, the sequence of calls leading to the crash inside Fselect_frame > is as follows: > > Fselect_frame > -> do_switch_frame > -> Fredirect_frame_focus > -> w32_frame_rehighlight / XTframe_rehighlight > -> x_frame_rehighlight > -> frame_highlight > -> x_update_cursor > -> update_cursor_in_window_tree > -> update_window_cursor > -> display_and_set_cursor > -> erase_phys_cursor > -> window_text_bottom_y > -> die > > My conclusion after studying this is that everything that happens > below Fselect_frame is reasonable: we switch to the frame and redraw > the cursor in all of its windows. In particular, > update_cursor_in_window_tree simply walks the entire window tree of > the newly selected frame. I don't see how we can avoid any of this > when selected_window is nil, because selected_window has nothing to do > with the windows that are being processed. None of these functions > even references selected_window, which is TRT. The first place that > does reference selected_window is the CURRENT_MODE_LINE_HEIGHT macro > used in window_text_bottom_y, and that leads to the abort. > > So I see 2 ways to prevent this particular problem: > > 1) Handle the case of selected_window == Qnil in > CURRENT_MODE_LINE_FACE_ID. > > 2) Change the code of Fset_window_configuration and Fselect_window, > to have some other way of preventing the latter from storing point > in the old selected window, without setting selected_window to > nil. > > Any other ideas are welcome. >