From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Assertion failure in set_iterator_to_next Date: Mon, 12 Apr 2010 00:12:08 +0300 Message-ID: <83zl19y9qv.fsf@gnu.org> References: <83633yznmf.fsf@gnu.org> <831velzwio.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1271020338 587 80.91.229.12 (11 Apr 2010 21:12:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 11 Apr 2010 21:12:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 11 23:12:16 2010 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.69) (envelope-from ) id 1O14Ry-0007CC-Mn for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 23:12:15 +0200 Original-Received: from localhost ([127.0.0.1]:56440 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O14Ry-0006OY-26 for ged-emacs-devel@m.gmane.org; Sun, 11 Apr 2010 17:12:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O14Rs-0006Ng-Hv for emacs-devel@gnu.org; Sun, 11 Apr 2010 17:12:08 -0400 Original-Received: from [140.186.70.92] (port=42077 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O14Rr-0006Mc-14 for emacs-devel@gnu.org; Sun, 11 Apr 2010 17:12:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O14Rp-0007Tv-8Z for emacs-devel@gnu.org; Sun, 11 Apr 2010 17:12:06 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:57341) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O14Rp-0007Tl-1V for emacs-devel@gnu.org; Sun, 11 Apr 2010 17:12:05 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L0Q00A00DH5ZO00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 12 Apr 2010 00:12:03 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.74.198]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L0Q00AE3DK2C920@a-mtaout20.012.net.il>; Mon, 12 Apr 2010 00:12:03 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:123505 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Sun, 11 Apr 2010 16:04:05 -0400 > > > /* Get the next character, maybe multibyte. */ > > p = BYTE_POS_ADDR (IT_BYTEPOS (*it)); > > if (it->multibyte_p && !ASCII_BYTE_P (*p)) > > it-> c = STRING_CHAR_AND_LENGTH (p, it->len); <<<<<<<<< > > else > > it-> c = *p, it->len = 1; <<<<<<<<< > > Oh, thank you very much. I searched for this spot and couldn't find it > (I grepped with a pattern like "->len =", which only caught the second > line which couldn't explain why I was getting it->len==3. > That should help me move forward. > > > Since you are saying this is an ASCII buffer, are charpos and bytepos > > at least identical? > > Yes, they're identical before the assignment to IT_CHARPOS and > IT_BYTEPOS, but since it->len==3 a discrepancy of 2 appears which then > triggers the subsequent xassert. If this is an all-ASCII buffer, you should be able to say (gdb) watch it->len if it->len > 1 and see all the possible suspects. I would suggest to invoke "M-x redraw-display" after setting this watchpoint, because that performs a full redisplay and will iterate over all the characters in the buffer, its overlays, etc. You may also find the following commands handy for tracking this issue: (gdb) pit (gdb) pgrowx it->glyph_row The first will show you the current state of the iterator (struct it), the latter will show the glyphs that have been assembled so far in the line that is being produced, together with the source (buffer, string, etc.) from which every glyph comes. Just remember that using `pit' at arbitrary places may catch it out of sync, like it->c and it->len that do not match IT_CHARPOS(*it). You can also display previously produced glyph rows like this: (gdb) pgrowx it->glyph_row - 1 (gdb) pgrowx it->glyph_row - 2 etc., you get the point. Finally, (gdb) pgrowx MATRIX_ROW(it->w->desired_matrix,N) will display the Nth glyph row of the glyph matrix being constructed, which will normally be the Nth screen line (zero-based) on the updated display of the window it->w.