From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#28710: 27.0.50; eassert failure in maybe_produce_line_number Date: Fri, 06 Oct 2017 11:38:48 +0300 Message-ID: <83wp48vffr.fsf@gnu.org> References: <8760buwnne.fsf@gmail.com> <83d162xahp.fsf@gnu.org> <87bmllxieq.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1507279229 25617 195.159.176.226 (6 Oct 2017 08:40:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Oct 2017 08:40:29 +0000 (UTC) Cc: 28710@debbugs.gnu.org To: Alex Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 06 10:40:18 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e0OB5-0004vT-Ew for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Oct 2017 10:40:15 +0200 Original-Received: from localhost ([::1]:43566 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e0OBB-0001XS-9V for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Oct 2017 04:40:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e0OAy-0001T2-Qd for bug-gnu-emacs@gnu.org; Fri, 06 Oct 2017 04:40:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e0OAs-0002Wj-NR for bug-gnu-emacs@gnu.org; Fri, 06 Oct 2017 04:40:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43447) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e0OAs-0002Wd-KJ for bug-gnu-emacs@gnu.org; Fri, 06 Oct 2017 04:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e0OAs-0005wi-DZ for bug-gnu-emacs@gnu.org; Fri, 06 Oct 2017 04:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Oct 2017 08:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28710 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28710-submit@debbugs.gnu.org id=B28710.150727915722783 (code B ref 28710); Fri, 06 Oct 2017 08:40:02 +0000 Original-Received: (at 28710) by debbugs.gnu.org; 6 Oct 2017 08:39:17 +0000 Original-Received: from localhost ([127.0.0.1]:52128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e0OA9-0005vP-0l for submit@debbugs.gnu.org; Fri, 06 Oct 2017 04:39:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e0OA7-0005vD-79 for 28710@debbugs.gnu.org; Fri, 06 Oct 2017 04:39:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e0O9z-00027u-0s for 28710@debbugs.gnu.org; Fri, 06 Oct 2017 04:39:10 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e0O9q-0001zi-9v; Fri, 06 Oct 2017 04:38:58 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4518 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e0O9p-0004R2-9t; Fri, 06 Oct 2017 04:38:57 -0400 In-reply-to: <87bmllxieq.fsf@gmail.com> (message from Alex on Thu, 05 Oct 2017 17:51:41 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138005 Archived-At: merge 28710 27668 thanks > From: Alex > 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.