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#6621: Emacs crash when trying to report emacs crash Date: Wed, 14 Jul 2010 23:42:55 +0300 Message-ID: <83k4oxhk1c.fsf@gnu.org> References: <83d3urshi9.fsf@gnu.org> <834og3s1r0.fsf@gnu.org> <83pqyqqx9y.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1279141233 8526 80.91.229.12 (14 Jul 2010 21:00:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Jul 2010 21:00:33 +0000 (UTC) Cc: 6621@debbugs.gnu.org To: Yair F Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 14 23:00:31 2010 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 1OZ94A-0007Ug-O0 for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Jul 2010 23:00:31 +0200 Original-Received: from localhost ([127.0.0.1]:48627 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZ948-00044u-Qo for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Jul 2010 17:00:28 -0400 Original-Received: from [140.186.70.92] (port=45339 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZ942-00044A-5s for bug-gnu-emacs@gnu.org; Wed, 14 Jul 2010 17:00:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZ940-0007K5-2Q for bug-gnu-emacs@gnu.org; Wed, 14 Jul 2010 17:00:21 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35485) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZ940-0007Jv-10 for bug-gnu-emacs@gnu.org; Wed, 14 Jul 2010 17:00:20 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OZ8q9-0002gy-Vm; Wed, 14 Jul 2010 16:46:02 -0400 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: Wed, 14 Jul 2010 20:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6621 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6621-submit@debbugs.gnu.org id=B6621.127914031510338 (code B ref 6621); Wed, 14 Jul 2010 20:46:01 +0000 Original-Received: (at 6621) by debbugs.gnu.org; 14 Jul 2010 20:45:15 +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 1OZ8pP-0002gg-6p for submit@debbugs.gnu.org; Wed, 14 Jul 2010 16:45:15 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZ8pM-0002ga-WD for 6621@debbugs.gnu.org; Wed, 14 Jul 2010 16:45:14 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L5K00400ERGXL00@a-mtaout20.012.net.il> for 6621@debbugs.gnu.org; Wed, 14 Jul 2010 23:44:53 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.120.144]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L5K000AZEYSVXC0@a-mtaout20.012.net.il>; Wed, 14 Jul 2010 23:44:53 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 14 Jul 2010 16:46:01 -0400 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:38522 Archived-At: > Date: Wed, 14 Jul 2010 20:54:33 +0300 > From: Yair F > Cc: handa@m17n.org, 6621@debbugs.gnu.org > > > My Emacs is not compiled with -DENABLE_CHECKING, so the assert > > triggered here is a no-op for me, and Emacs works for me just fine > > with this recipe. > I have a slight suspicion that this relates to OTF/XFT font handling. > You build on Windows right? Yes. > > Finally, does the problem persist if you turn off > > auto-composition-mode before pasting the text? > As expected, turning off auto-composition-mode prevents the crash. Handa-san, could you take a look at this crash, please? > (gdb) up > #1 0x0809cd6b in set_iterator_to_next (it=0xbfffdee4, reseat_p=1) at > xdisp.c:6254 > 6254 xassert (IT_BYTEPOS (*it) == CHAR_TO_BYTE (IT_CHARPOS (*it))); > (gdb) pit > cur=151[277] pos=150[276] start=128[235] end=151 stop=151 face=16 MB ch='@' > vpos=6 hpos=17 y=102 lvy=510 x=114 vx=0-640 w=8 a+d=13+4=17 max=13+4=17 > (gdb) pgrowx it->glyph_row > TEXT: 17 glyphs > 0 0: COMP[47 (0..1)] pos=128 w=9 a+d=13+4 face=16 MB > 1 9: CHAR[0x5e7] pos=130 blev=0,btyp=UNDEF w=9 a+d=13+4 face=16 MB > 2 18: CHAR[ ] pos=131 blev=0,btyp=UNDEF w=8 a+d=13+4 MB > 3 26: COMP[49 (0..1)] pos=132 w=9 a+d=13+4 face=16 MB > 4 35: CHAR[0x5e5] pos=134 blev=0,btyp=UNDEF w=7 a+d=13+4 face=16 MB > 5 42: CHAR[ ] pos=135 blev=0,btyp=UNDEF w=8 a+d=13+4 MB > 6 50: COMP[51 (0..1)] pos=136 w=3 a+d=13+4 face=16 MB > 7 53: COMP[53 (0..1)] pos=138 w=8 a+d=13+4 face=16 MB > 8 61: CHAR[0x5d9] pos=140 blev=0,btyp=UNDEF w=3 a+d=13+4 face=16 MB > 9 64: CHAR[ ] pos=141 blev=0,btyp=UNDEF w=8 a+d=13+4 MB > 10 72: COMP[55 (0..1)] pos=142 w=6 a+d=13+4 face=16 MB > 11 78: COMP[57 (0..1)] pos=144 w=9 a+d=13+4 face=16 MB > 12 87: CHAR[0x5e2] pos=146 blev=0,btyp=UNDEF w=8 a+d=13+4 face=16 MB > 13 95: COMP[35 (0..0)] pos=147 w=3 a+d=13+4 face=16 MB > 14 98: COMP[35 (1..1)] pos=149 w=0 a+d=13+4 face=16 MB > 15 98: CHAR[^] pos=150 blev=0,btyp=UNDEF w=8 a+d=13+4 face=17 MB > 16 106: CHAR[@] pos=150 blev=0,btyp=UNDEF w=8 a+d=13+4 face=17 MB It somehow thinks there's a null character (displayed as "^@" at the end of the glyph row above) at character position 150. This is at least a symptom of the assertion violation, if not its cause. Hmm... maybe these two lines a little ways up before the assert IT_CHARPOS (*it) += it->cmp_it.nchars; IT_BYTEPOS (*it) += it->cmp_it.nbytes; overstepped the end of the buffer? This glyph, the one before the null character, also looks suspicious: > 14 98: COMP[35 (1..1)] pos=149 w=0 a+d=13+4 face=16 MB Buffer position 149 is the newline, so why it is composed? In general, a newline should not appear in the glyph row, because it does not take any screen space.