bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#27668: 26.0.50; Crash with display-line-numbers t
Date: Thu, 13 Jul 2017 19:24:13 +0300

> From: Robert Pluim <address@hidden>
> Date: Thu, 13 Jul 2017 10:28:42 +0200
> 
> > 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.

It's nice that a clear pattern emerges, but I still cannot see how
that could happen...

I think next thing to try is to see where does the used[1] count
becomes too large.  I suggest to run Emacs under GDB with the
following breakpoint on a line immediately after the call to
PRODUCE_GLYPHS in display_line:

  (gdb) break xdisp.c:21374 if it->glyph_row->used[1] > 90

This assumes that you're windows are never wider than 90 columns; if
that's not true, enlarge the number as needed to prevent the
breakpoint from breaking in legitimate cases.  When this breaks,
please show the backtrace.

Another idea is to set the following breakpoint inside
maybe_produce_line_number:

  (gdb) break xdisp.c:21010 if it->glyph_row != 0 && it->glyph_row->used[1] > 0

Line 21010 is this:

  short *u = it->glyph_row ? &it->glyph_row->used[TEXT_AREA] : NULL;

There's a hidden assumption in the code that maybe_produce_line_number
is called when no glyphs were produced for the screen line yet.  Maybe
that assumption is wrong.

Btw, what version of GCC do you use?

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]