GNU bug report logs - #28710
27.0.50; eassert failure in maybe_produce_line_number

Previous Next

Package: emacs;

Reported by: Alex <agrambot <at> gmail.com>

Date: Wed, 4 Oct 2017 22:33:02 UTC

Severity: normal

Tags: moreinfo

Merged with 27668

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


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 28710 <at> debbugs.gnu.org
Subject: bug#28710: 27.0.50; eassert failure in maybe_produce_line_number
Date: Sun, 08 Oct 2017 09:29:46 +0300
> From: Alex <agrambot <at> gmail.com>
> Cc: 28710 <at> 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.




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.