GNU bug report logs - #27668
26.0.50; Crash with display-line-numbers t

Previous Next

Package: emacs;

Reported by: Robert Pluim <rpluim <at> gmail.com>

Date: Wed, 12 Jul 2017 13:44:02 UTC

Severity: normal

Tags: moreinfo

Merged with 28710

Found in versions 26.0.50, 27.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#27668: 26.0.50; Crash with display-line-numbers t
Date: Thu, 13 Jul 2017 10:28:42 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Robert Pluim <rpluim <at> 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





This bug report was last modified 7 years and 277 days ago.

Previous Next


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