bug#27668: 26.0.50; Crash with display-line-numbers t

[Robert Pluim <rpluim@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Wed, 12 Jul 2017 20:26:50 +0200
>> 
>> 125 2000: CHAR[r] pos=9542 blev=0,btyp=L w=16 a+d=25+6 face=28 MB
>> 126 2016: CHAR[e] pos=9543 blev=0,btyp=L w=16 a+d=25+6 face=28 MB
>> 127 2032: CHAR[s] pos=9544 blev=0,btyp=L w=16 a+d=25+6 face=28 MB
>> 128 2048: CHAR[e] pos=9545 blev=0,btyp=L w=16 a+d=25+6 face=28 MB
>> 129 2064: CHAR[n] pos=9546 blev=0,btyp=L w=16 a+d=25+6 face=28 MB
>> 130 2080: CHAR[t] pos=9547 blev=0,btyp=L w=16 a+d=25+6 face=28 MB
>> 131 2096: CHAR[e] pos=9548 blev=0,btyp=L w=16 a+d=25+6 face=28 MB
>> 132 2112: CHAR[d] pos=9549 blev=0,btyp=L w=16 a+d=25+6 face=28 MB
>> 133 2128: CHAR[ ] pos=0 blev=0,btyp=B w=16 a+d=25+6 face=28 MB
>> 
>> Hmm. Is it normal for the text on that line to be shown twice here?
>
> No, of course not.  Everything beyond the first glyph whose pos is
> zero (that's the glyph that stands for the newline, it is there so we
> could put the cursor at EOL) shouldn't be there.
>
>> The crash is always in compute_line_metrics. I'll continue to run
>> under gdb, and see if I can find a recipe.
>
> If it's always in compute_line_metrics, then please see if the value
> of row->used[1] is always about twice the correct one.  If it is,
> perhaps we will be able to come up with a breakpoint or watchpoint
> condition that will catch the code which is responsible.

It's always approximately twice the correct one. In the two cases I
have so far it's 67:138 and 47:98. That's a ratio of n:(2n + 4) in
both cases.

Regards

Robert