From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: xdisp.c 1.794 breaks Mac OS X (Carbon) Date: 16 Dec 2002 01:45:55 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5xznr694fw.fsf@kfs2.cua.dk> References: <7206041.1039633587298.JavaMail.steventamm@mac.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1039996001 1703 80.91.224.249 (15 Dec 2002 23:46:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 15 Dec 2002 23:46:41 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18NiT2-0000RD-00 for ; Mon, 16 Dec 2002 00:46:40 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18NigF-0003b5-00 for ; Mon, 16 Dec 2002 01:00:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18NiT9-0004tr-03 for emacs-devel@quimby.gnus.org; Sun, 15 Dec 2002 18:46:47 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18NiSq-0004sD-00 for emacs-devel@gnu.org; Sun, 15 Dec 2002 18:46:28 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18NiSm-0004r6-00 for emacs-devel@gnu.org; Sun, 15 Dec 2002 18:46:27 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18NiSl-0004oz-00 for emacs-devel@gnu.org; Sun, 15 Dec 2002 18:46:23 -0500 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id A31C57C012; Sun, 15 Dec 2002 23:46:15 +0000 (GMT) Original-To: Steven Tamm In-Reply-To: <7206041.1039633587298.JavaMail.steventamm@mac.com> Original-Lines: 93 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:10151 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10151 Steven Tamm writes: > Just updated to latest source and a change in to xdisp.c:row_containing_pos causes the osx build to break reliably after scrolling through a long document. Reverting to 1.793 fixes everything > > The problem is that row is NULL for set_cursor_from_row in try_window_id. Should there be a check for row=NULL in try_window_id? Here is the stack trace. > > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000006c > Thread 0 Crashed: > #0 0x00020488 in set_cursor_from_row (xdisp.c:9447) > #1 0x00025d5c in try_window_id (xdisp.c:11774) > #2 0x000230e4 in redisplay_window (xdisp.c:10478) > #3 0x000203f8 in redisplay_window_0 (xdisp.c:9417) > #4 0x000c9518 in internal_condition_case_1 (eval.c:1393) > > Let me know if more details are needed... > > -Steven > Hi Steven, I "fixed" this problem by testing that the "row" was non-NULL before calling set_cursor_from_row. However, RMS has asked me to try finding the actual cause the this error: > + 2002-12-11 Kim F. Storm > + > + * xdisp.c (try_window_id): Don't call set_cursor_from_row if > + row_containing_pos returned NULL. > + > > This is an obvious way to avoid the crash, but is it a correct fix? I > don't know. If it is not correct, the result is likely to be > another occasional bug that puts the cursor in the wrong place. > That would be hard to debug. > > Could you please check if it is correct? One way to check > is to add > > else > abort (); > > after each of those if statements, and run under GDB. When it stops > at `abort', type `return' so it won't die, then either (1) step > through and see if the subsequent actions look reasonable or (2) > just continue and see if the cursor comes out in the right place. > If you can still reproduce the crash (after adding the else abort();), could you try to follow RMS' instructions above. Now, if the cursor does indeed not appear in the right position, could you try the following patch that RMS suggested to fix this: The change below may fix the problem, but I am not certain it is correct. Anyway, can you please run under GDB all the time, with a breakpoint set in set_cursor_from_row like this? b set_cursor_from_row if row==0 If it stops there, please try calling row_containing_pos the same way it was called by try_window_id, but step through it and see precisely why it returns zero. In particular, what line does it return at? (Show us the code on and around that line, not just the line number!) What is the value of MATRIX_ROW_BOTTOM_Y (row) for the last row that it thinks about? And what is last_y? Should it have found PT in the previous row? *** xdisp.c.~1.794.~ Sun Dec 8 16:06:46 2002 --- xdisp.c Tue Dec 10 22:22:07 2002 *************** *** 11514,11520 **** /* Give up if we have gone too far. */ if (end && row >= end) return NULL; ! if (MATRIX_ROW_BOTTOM_Y (row) >= last_y) return NULL; /* If it is in this row, return this row. */ --- 11516,11522 ---- /* Give up if we have gone too far. */ if (end && row >= end) return NULL; ! if (MATRIX_ROW_BOTTOM_Y (row) > last_y) return NULL; /* If it is in this row, return this row. */ -- Kim F. Storm http://www.cua.dk