GNU bug report logs - #11199
24.0.95; killing right-to-left text at eob leads to inconsistent state

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Welsh Duggan <md5i <at> md5i.com>
Cc: 11199 <at> debbugs.gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state
Date: Mon, 09 Apr 2012 00:07:42 +0300

> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Cc: mituharu <at> math.s.chiba-u.ac.jp,  11199 <at> debbugs.gnu.org
> Date: Sun, 08 Apr 2012 16:49:14 -0400
> 
> > Btw, if you set bidi-display-reordering nil in *scratch* before typing
> > the recipe, does the crash still happen?
> 
> It does not.  If you need me to poke around just point me in the right
> direction.

Well, it would help if you could find out how does row->end get out of
sync with row->maxpos, for this specific row.  Both end and maxpos are
set near the end of display_line, around line 19480 of xdisp.c.  They
are identical when bidi-display-reordering is turned off, but
different when it's on (because maxpos-1 gives the largest buffer
position of the characters in the row, while end-1 gives the buffer
position of the rightmost character on display).  In this case, it
looks like row->end came from a totally different screen line, the one
that was killed by C-k.  I wonder how could that happen and which code
is responsible.  Perhaps some code tries to reuse existing rows, and
goofs.

One way to find out is to step through the code in display_line that
computes row->end and row->maxpos for the offending line, the one that
starts with "  (insert", and then put a hardware watchpoint on the
'end' field of that glyph_row structure, and see when it triggers.

TIA

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.