bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

[Eli Zaretskii]

merge 28710 27668
thanks

> From: Alex <agrambot@gmail.com>
> Cc: 28710@debbugs.gnu.org
> Date: Thu, 05 Oct 2017 17:51:41 -0600
> 
> > It doesn't crash for me here.  But since it's hardly repeatable for
> > you, I'm not surprised.
> 
> What about using the below recipe?

Thanks, but still no cigar.

> > If you go to frame #3, in maybe_produce_line_number, and type
> >
> >   (gdb) pgrowx it->glyph_row
> >
> > what does that produce?  (You will need to source src/.gdbinit for the
> > pgrowx command to work.)
> 
> TEXT: 34 glyphs
>   0    0: CHAR[ ] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   1    9: CHAR[3] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   2   18: CHAR[1] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   3   27: CHAR[3] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   4   36: CHAR[0] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   5   45: CHAR[ ] pos=-1 blev=2,btyp=EN w=9 a+d=14+4 face=35 MB AVOID
>   6   54: CHAR[@] pos=123808 blev=0,btyp=L w=9 a+d=14+4 MB

It sounds like you've rediscovered bug#27668.  Robert Pluim lost the
ability to reproduce it when we were close to catching the offending
code, but maybe you will be able to pick up where he left off?  In a
nutshell, the glyph rows where display_line produces glyphs are not
cleared, so they still hold the glyphs produced by some previous code
in the display engine.  The question is where should we add a call to
clear_glyph_matrix to force the glyph rows to be cleared at the
beginning of display_line.

I wrote instructions for a debugging session to find that out, see

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27668#89

Instead of "r -Q", type just "run" to run Emacs as usual, or even
attach to an already running Emacs with "gdb -p", set the breakpoint,
and type "continue.  The "Inside Emacs" part will have to be replaced
with your recipe, up to and including step 5, and you should invoke
redraw-display just before hitting the final RET in step 6, the one
that triggers the assertion.  After performing the GDB commands and
continuing Emacs, hit RET, and post the backtraces from every time the
watchpoint set by those GDB commands is hit.  I hope we will then see
the offending code that needs to be fixed.

Let me know if you need me to rewrite the instructions to fit your
case exactly.

> > Btw, your recipe didn't quite work for me: the first step failed when
> > I pressed RET "on the first line" of the buffer presented by "M-x
> > magit-status" in the current release branch tip.  It said there was
> > nothing to show about that line.  I needed to find a suitable line
> > further down in the buffer.  Am I missing something here?  Can you
> > specify precise steps, assuming I know nothing about using Magit?
> 
> That's odd, since I believe unless there was a git error the first line
> should start with "Head:" and pressing RET on it shows the commit at
> HEAD. Maybe there's another situation where that's not the case.

What if HEAD is a merge-commit?  I think this is what I got when I
tried.  Anyway, this is just a tangential issue.

> Just to specify a commit, try M-x magit-show-commit RET 92045f45 RET in
> an Emacs repo and press RET on the following line:
> +@code{file-symlink-p}, @code{file-system-info}

You mean "C-u M-x magit-show-commit", right?  Tried this as well,
still no assertion violation.

Thanks.

P.S. Btw, I'm debugging this in the emacs-26 branch, so perhaps so
should you, to avoid any irrelevant differences between what you and I
see.  I tried reproducing the assertion violation in both branches,
and failed in both.