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: Wed, 12 Jul 2017 22:01:28 +0300 Message-ID: <834luhiinr.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1499886207 14392 195.159.176.226 (12 Jul 2017 19:03:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Jul 2017 19:03:27 +0000 (UTC) To: 27668@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 12 21:03: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 1dVMuo-00036Y-Jx for geb-bug-gnu-emacs@m.gmane.org; Wed, 12 Jul 2017 21:03:14 +0200 Original-Received: from localhost ([::1]:55270 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVMut-00065X-U7 for geb-bug-gnu-emacs@m.gmane.org; Wed, 12 Jul 2017 15:03:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVMuh-00063r-JC for bug-gnu-emacs@gnu.org; Wed, 12 Jul 2017 15:03:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVMuc-0001Dn-Ml for bug-gnu-emacs@gnu.org; Wed, 12 Jul 2017 15:03:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33090) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dVMuc-0001Df-KW for bug-gnu-emacs@gnu.org; Wed, 12 Jul 2017 15:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dVMuc-0003n1-DN for bug-gnu-emacs@gnu.org; Wed, 12 Jul 2017 15:03: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: Wed, 12 Jul 2017 19:03: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.149988612814502 (code B ref -1); Wed, 12 Jul 2017 19:03:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 12 Jul 2017 19:02:08 +0000 Original-Received: from localhost ([127.0.0.1]:35767 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVMtk-0003lq-3j for submit@debbugs.gnu.org; Wed, 12 Jul 2017 15:02:08 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37193) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVMti-0003lN-02 for submit@debbugs.gnu.org; Wed, 12 Jul 2017 15:02:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVMtb-0000rz-Td for submit@debbugs.gnu.org; Wed, 12 Jul 2017 15:02:00 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:59578) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dVMtb-0000ru-Qv for submit@debbugs.gnu.org; Wed, 12 Jul 2017 15:01:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVMta-0005X6-KX for bug-gnu-emacs@gnu.org; Wed, 12 Jul 2017 15:01:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVMtV-0000qS-Qf for bug-gnu-emacs@gnu.org; Wed, 12 Jul 2017 15:01:58 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVMtV-0000qO-NJ for bug-gnu-emacs@gnu.org; Wed, 12 Jul 2017 15:01:53 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3046 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dVMtT-0007vb-05 for bug-gnu-emacs@gnu.org; Wed, 12 Jul 2017 15:01:53 -0400 In-reply-to: <871spl5x5h.fsf@gmail.com> (message from Robert Pluim on Wed, 12 Jul 2017 20:26:50 +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:134477 Archived-At: > From: Robert Pluim > Date: Wed, 12 Jul 2017 20:26:50 +0200 > > 125 2000: CHAR[r] pos=9542 blev=0,btyp=L w=16 a+d=25+6 face=28 MB > 126 2016: CHAR[e] pos=9543 blev=0,btyp=L w=16 a+d=25+6 face=28 MB > 127 2032: CHAR[s] pos=9544 blev=0,btyp=L w=16 a+d=25+6 face=28 MB > 128 2048: CHAR[e] pos=9545 blev=0,btyp=L w=16 a+d=25+6 face=28 MB > 129 2064: CHAR[n] pos=9546 blev=0,btyp=L w=16 a+d=25+6 face=28 MB > 130 2080: CHAR[t] pos=9547 blev=0,btyp=L w=16 a+d=25+6 face=28 MB > 131 2096: CHAR[e] pos=9548 blev=0,btyp=L w=16 a+d=25+6 face=28 MB > 132 2112: CHAR[d] pos=9549 blev=0,btyp=L w=16 a+d=25+6 face=28 MB > 133 2128: CHAR[ ] pos=0 blev=0,btyp=B w=16 a+d=25+6 face=28 MB > > Hmm. Is it normal for the text on that line to be shown twice here? No, of course not. Everything beyond the first glyph whose pos is zero (that's the glyph that stands for the newline, it is there so we could put the cursor at EOL) shouldn't be there. > The crash is always in compute_line_metrics. I'll continue to run > under gdb, and see if I can find a recipe. 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.