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#27668: 26.0.50; Crash with display-line-numbers t Date: Thu, 13 Jul 2017 19:24:13 +0300 Message-ID: <83r2xkgv9u.fsf@gnu.org> References: <87k23d7ovv.fsf@gmail.com> <83inixiv0m.fsf@gnu.org> <877ezd7luq.fsf@gmail.com> <83bmopitky.fsf@gnu.org> <87vamx65x0.fsf@gmail.com> <837ezdiq3z.fsf@gnu.org> <871spl5x5h.fsf@gmail.com> <834luhiinr.fsf@gnu.org> <8760ewviyt.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1499963128 9118 195.159.176.226 (13 Jul 2017 16:25:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Jul 2017 16:25:28 +0000 (UTC) To: 27668@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 13 18:25:21 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 1dVgvW-0001U9-9G for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Jul 2017 18:25:18 +0200 Original-Received: from localhost ([::1]:32910 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVgvV-0000uR-L3 for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Jul 2017 12:25:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVgvL-0000nA-JS for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2017 12:25:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVgvG-0000FB-Lx for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2017 12:25:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34591) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dVgvG-0000Ez-J9 for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2017 12:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dVgvG-0006KR-B2 for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2017 12:25: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: Thu, 13 Jul 2017 16:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27668 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.149996307724292 (code B ref -1); Thu, 13 Jul 2017 16:25:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 13 Jul 2017 16:24:37 +0000 Original-Received: from localhost ([127.0.0.1]:37268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVgur-0006Jk-6C for submit@debbugs.gnu.org; Thu, 13 Jul 2017 12:24:37 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVgup-0006JX-Cp for submit@debbugs.gnu.org; Thu, 13 Jul 2017 12:24:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVguj-0008Tv-9j for submit@debbugs.gnu.org; Thu, 13 Jul 2017 12:24:30 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:45796) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dVguj-0008Tq-6X for submit@debbugs.gnu.org; Thu, 13 Jul 2017 12:24:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVgui-0008Tw-0A for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2017 12:24:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVgud-0008SX-3W for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2017 12:24:27 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVguc-0008SR-W9 for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2017 12:24:23 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3493 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dVgub-0007Ww-T7 for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2017 12:24:22 -0400 In-reply-to: <8760ewviyt.fsf@gmail.com> (message from Robert Pluim on Thu, 13 Jul 2017 10:28:42 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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:134509 Archived-At: > From: Robert Pluim > 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.