From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Tracking down assertion failure Date: Wed, 12 Mar 2008 21:30:48 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205372279 24127 80.91.229.12 (13 Mar 2008 01:37:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Mar 2008 01:37:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 13 02:38:27 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JZcOm-0005Qr-GP for ged-emacs-devel@m.gmane.org; Thu, 13 Mar 2008 02:38:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZcOD-0008NQ-FH for ged-emacs-devel@m.gmane.org; Wed, 12 Mar 2008 21:37:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JZcO9-0008N3-Ut for emacs-devel@gnu.org; Wed, 12 Mar 2008 21:37:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JZcO7-0008MC-3n for emacs-devel@gnu.org; Wed, 12 Mar 2008 21:37:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZcO6-0008M3-Vc for emacs-devel@gnu.org; Wed, 12 Mar 2008 21:37:43 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JZcO3-0001TE-8g; Wed, 12 Mar 2008 21:37:39 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgFAPQh2EfO+JwVUGdsb2JhbACQZwEBOZQTgQY X-IronPort-AV: E=Sophos;i="4.25,491,1199682000"; d="scan'208";a="15966802" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 12 Mar 2008 21:37:38 -0400 Original-Received: from ceviche.home ([206.248.156.21]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id TEY33738; Wed, 12 Mar 2008 21:37:38 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 55D1FB4055; Wed, 12 Mar 2008 21:30:48 -0400 (EDT) In-Reply-To: (Eli Zaretskii's message of "Thu, 13 Mar 2008 00:06:15 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:92350 Archived-At: >> /* Skip from tlbufpos to PT and see where it is. Note that >> PT may be in invisible text. If so, we will end at the >> next visible position. */ >> init_iterator (&it, w, CHARPOS (tlbufpos), BYTEPOS (tlbufpos), >> NULL, DEFAULT_FACE_ID); >> xassert (IT_BYTEPOS (it) == CHAR_TO_BYTE (IT_CHARPOS (it))); >> >> the problem is that as I keep adding such assertions earlier and earlier >> in the code I seem to start hitting another problem: I'm not sure at >> which point this condition should be true and and at which point it's OK >> for it not to be true (because the charpos and bytepos recorded refer >> to out-of-data data which will/should simply not be used). >> >> Can someone help me out? > I may be forgetting something, but isn't the iterator moving by > characters? It uses the pair > IT_BYTEPOS (*it) += it->len; > IT_CHARPOS (*it) += 1; > to advance, so IT_BYTEPOS and IT_CHARPOS should always be in sync, > right? Am I missing something? Yes, they should. I'm pretty sure that the above xassert should not fail. Yet it does (typically the bytepos is 1 larger than the charpos, even tho the buffer contains only ascii, and typically it happens when moving around the buffer with the arrow keys, it seems to have to do with handling of the cursor). The problem is that when we enter the cursor code, it's not clear to me which charpos/bytepos pairs are expected to be valid and which ones are expected to be potentially out-of-date and I don't understand either enough about how/when we check them being up-to-date. The bug cannot be reproduced deterministically, but I hit it several times a day. After adding xasserts similar to the above further up the call chain, all I managed to get is that those asserts fail more often, but I'm not convinced that their failure is really a bug, because I'm not sure whether the values I check should actually be up-to-date. Stefan