bug#28710: 27.0.50; eassert failure in maybe_produce_line_number

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: 28710@debbugs.gnu.org
> Date: Sat, 07 Oct 2017 17:05:34 -0600
> 
> > 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.
> 
> Okay, I've pasted the output below. 2 watchpoints triggered right after
> M-x redraw-display, and I only get the third before the assertion.
> 
> After your recipe, you mention update_display and how it runs after
> Emacs "redrawn the window to the glass", so it should be noted that the
> assertion violated is triggered before the buffer with
> display-line-numbers is displayed.

Thanks, but I need a backtrace at each hit of the watchpoint.  The GDB
session I posted defined commands to be executed at the watchpoint, so
such a backtrace should have been executed whenever the watchpoint
triggered.  Those backtraces is what I need to determine where is the
enabled_p flag set, because one of those places is unexpected by the
code.  It's probably the last, but given what you posted, I cannot
see where did the call to prepare_desired_row originated.

Thanks.