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

[Eli Zaretskii]

> 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.