From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Scott Corley Newsgroups: gmane.emacs.bugs Subject: bug#32951: emacs Lock-Up-Crash Bug report and patch Date: Fri, 5 Oct 2018 21:30:25 -0500 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005bacb20577862c62" X-Trace: blaine.gmane.org 1538805656 16413 195.159.176.226 (6 Oct 2018 06:00:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Oct 2018 06:00:56 +0000 (UTC) To: 32951@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 06 08:00:52 2018 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 1g8fdz-0004AG-Nr for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Oct 2018 08:00:51 +0200 Original-Received: from localhost ([::1]:38096 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g8fg6-0001B3-Bt for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Oct 2018 02:03:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g8ffT-00011D-OD for bug-gnu-emacs@gnu.org; Sat, 06 Oct 2018 02:02:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g8fUU-0007yp-FL for bug-gnu-emacs@gnu.org; Sat, 06 Oct 2018 01:51:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34032) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g8fUU-0007yD-A8 for bug-gnu-emacs@gnu.org; Sat, 06 Oct 2018 01:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g8fUT-0006rC-VO for bug-gnu-emacs@gnu.org; Sat, 06 Oct 2018 01:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Scott Corley Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Oct 2018 05:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 32951 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.153880502126307 (code B ref -1); Sat, 06 Oct 2018 05:51:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 6 Oct 2018 05:50:21 +0000 Original-Received: from localhost ([127.0.0.1]:38290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g8fTo-0006qA-8t for submit@debbugs.gnu.org; Sat, 06 Oct 2018 01:50:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42603) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g8cMk-0001mS-W5 for submit@debbugs.gnu.org; Fri, 05 Oct 2018 22:30:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g8cMe-0002i7-7m for submit@debbugs.gnu.org; Fri, 05 Oct 2018 22:30:45 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:37170) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g8cMe-0002hh-1O for submit@debbugs.gnu.org; Fri, 05 Oct 2018 22:30:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g8cMc-0004qn-IQ for bug-gnu-emacs@gnu.org; Fri, 05 Oct 2018 22:30:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g8cMZ-0002cd-9H for bug-gnu-emacs@gnu.org; Fri, 05 Oct 2018 22:30:42 -0400 Original-Received: from mail-ua1-x943.google.com ([2607:f8b0:4864:20::943]:39005) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g8cMY-0002bE-Ud for bug-gnu-emacs@gnu.org; Fri, 05 Oct 2018 22:30:39 -0400 Original-Received: by mail-ua1-x943.google.com with SMTP id g18-v6so5371236uam.6 for ; Fri, 05 Oct 2018 19:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scorley-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=xFiO6QAI72srtzkxTCnbuc931d9wgxY3EEtn9tFtX5c=; b=SYLJoNRCMsrbeQnGesR1mndC9Xu49ml2iwJ9XjBJcps0opXEZFjXqDmQbG6CapzYEW RuX09l1pelUe7htgpmg1QZleMsSxPksb4AQKS0BqUR7R7dAECigsIUOvTs9dlVfNVvDc UMDxeCLN1g3b6bvHtVKY06sPWmMvOn+v50omOLGz/e/JzP5SnkQqHZ1XQLTARJx8hy/Q 627hOa6U8qOUkR4UahvVBj/mLm5EvJKWCAGBbkM/dy8R/76PPhDgu3Oki1ChUyQXsB7h YGLw2I0S1xvCt3S0QkU/UKxAX6jJzxawLMiA0hfLurjuvCS/04Y0ZtyaO6E8zP/jxfD9 0e9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xFiO6QAI72srtzkxTCnbuc931d9wgxY3EEtn9tFtX5c=; b=olzldjMyALoNnWScN7QQsaSn4OhqPwQ6qIDcva5dHDARjQP6zZ/Rq/MU1I4wiKQR0b DTEfVPdOE3TfNtEAlFP+j5qS0Gh9IAAqnYg39QcMzvQwtSRvwTYRkmhH/KuH4Un7213i 6SK1wSwiRHbi0DzbniBMMzN/wgjZAh9KIjtw8+LmixYRnHr8Mb7uM25076IeBklT+ocx 5g7yb9kVpFAiwu6cKazmIYqlVbz50mu8F5faPofF4W34vF89cZ2H+4AFLUHf8eokOweO TtSKOQJu9GlHxHQfd9Cj6RN4wsGwp4vaTfkrxUvmjrIs+mAQQ3+ABXVEVsWIIN1yZdwI 0bZQ== X-Gm-Message-State: ABuFfoi7QCoVRxZ2Es9sxmVfMUNllMRaY15959tsHtHRs+OAwDZFD7LR 2hnYmhPI92il/qOpVROAaVNCWV/Yz/s= X-Google-Smtp-Source: ACcGV63xedkqpYzt0Nwxr90RA8WtOrt96cnsB4kVHJEt5/BbsGJm2XIR0UkK8sAEVrMZDhH7k2GftA== X-Received: by 2002:ab0:e0c:: with SMTP id g12mr5703397uak.124.1538793037869; Fri, 05 Oct 2018 19:30:37 -0700 (PDT) Original-Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com. [209.85.221.177]) by smtp.gmail.com with ESMTPSA id r123-v6sm5671896vka.16.2018.10.05.19.30.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Oct 2018 19:30:37 -0700 (PDT) Original-Received: by mail-vk1-f177.google.com with SMTP id 125-v6so3416926vkx.13 for ; Fri, 05 Oct 2018 19:30:37 -0700 (PDT) X-Received: by 2002:a1f:1694:: with SMTP id 142-v6mr5345635vkw.43.1538793037074; Fri, 05 Oct 2018 19:30:37 -0700 (PDT) X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Mailman-Approved-At: Sat, 06 Oct 2018 01:50:18 -0400 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:150959 Archived-At: --0000000000005bacb20577862c62 Content-Type: text/plain; charset="UTF-8" If an emacs window exceeds 255 lines, it causes an unsigned char overflow in scroll.c:do_direct_scrolling The effect of this overflow is that do_direct_scrolling enters an infinite loop. This causes emacs to lock up in an unrecoverable way, and the process has to be killed. This bug can be reproduced in a number of ways: 1. Open up emacs on a very large display and expand the emacs window so that it is larger than 255 lines. Do some editing, add text to the window, enough that do_direct_scrolling is invoked. For example, opening and editing emacs/INSTALL will eventually cause the lockup. You may need to navigate through the file and/or delete and edit some lines. Once do_direct_scrolling function is invoked, it will enter an infinite loop and lock up emacs. (new 43" monitor in portrait mode is how I first encountered this bug). This happens in "-nw" mode and in X display mode. 2. If you don't have a large display, open up an X windows instance of emacs and decrease the font size until the window has more than 255 lines. Follow the editing example in (1) above, and emacs will lock up. 3. You can also reproduce in '-nw' mode on a normal size display by opening up a terminal window with a very small font size, enough to have more than 255 vertical lines. I can reproduce the bug using all of these methods on these and similar systems: Red Hat Enterprise Linux Server Release 7.3 (Maipo) Intel Xeon CPU E5-2667 V3 GNU Emacs 24.3.1 GNU Emacs 27.0.50 (built from master) macOS Mojave 2013 MacBook Pro Intel Core i7 GNU Emacs 25.3.1 Cause of unsigned char overflow: struct matrix_elt, used by do_direct_scrolling, in scroll.c, has three fields that are declared as unsigned char. It looks like they were previously declared as signed char, then changed to unsigned char, perhaps to fix a previous incarnation of this overflow. The fields in question are 'insertcount', 'deletecount' and 'writecount'. The patch below changes these fields to 'int'. The alloction of 'matrix_elt' is a small memory footprint (see allocation in scroll.c function 'scrolling_1') I can't see a justification for keeping these fields 'unsigned char'. On most systems, it is actually a challenge to create an emacs window larger than 255 lines, which is why I'm guessing this overflow hasn't come up before (I couldn't find bug report mentioning it). However, on a system with a 4k display in portrait mode, it is pretty easy to accidentally create a window this large. For example, if I am using a tmux display with reasonably-sized pane on a 4k monitor in portrait mode, and I happen to zoom the tmux pane to full screen, the emacs window will now be larger than 255 lines, emacs will enter an infinite loop, and the process will need to be killed. The overflow was confirmed by attaching to a crashed/looping emacs process with gdb, and stepping through the code, on different operating systems and machines. Changelog: 2018-10-05 Scott Corley * scroll.c (struct matrix_elt): change unsigned char fields to int fixes overflow lockup crash with window sizes > 255 lines. Here is the patch: --- src/scroll.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/scroll.c b/src/scroll.c index a29f2d37f5..240005b4e3 100644 --- a/src/scroll.c +++ b/src/scroll.c @@ -41,13 +41,13 @@ struct matrix_elt int deletecost; /* Number of inserts so far in this run of inserts, for the cost in insertcost. */ - unsigned char insertcount; + int insertcount; /* Number of deletes so far in this run of deletes, for the cost in deletecost. */ - unsigned char deletecount; + int deletecount; /* Number of writes so far since the last insert or delete for the cost in writecost. */ - unsigned char writecount; + int writecount; }; static void do_direct_scrolling (struct frame *, -- Thanks, Scott --0000000000005bacb20577862c62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If an emacs window exceeds 255 lines, it = causes an unsigned char overflow in
scroll.c:do_direct_scrolling

= The effect of this overflow is that do_direct_scrolling enters
an infini= te loop.
This causes emacs to lock up in an unrecoverable way, and the p= rocess has to
be killed.

This bug can be reproduced in a number o= f ways:

1. Open up emacs on a very large display and expand the emac= s window so that
=C2=A0 =C2=A0it is larger than 255 lines. Do some editi= ng, add text to the window,
=C2=A0 =C2=A0enough that do_direct_scrolling= is invoked.

=C2=A0 =C2=A0For example, opening and editing emacs/INS= TALL will eventually cause
=C2=A0 =C2=A0the lockup. You may need to navi= gate through the file and/or delete and
=C2=A0 =C2=A0edit some lines.=C2=A0 =C2=A0Once do_direct_scrolling function is invoked, it will enter a= n infinite
=C2=A0 =C2=A0loop and lock up emacs.

=C2=A0 =C2=A0(new= 43" monitor in portrait mode is how I first encountered this bug).=C2=A0 =C2=A0This happens in "-nw" mode and in X display mode.
2. If you don't have a large display, open up an X windows instan= ce of
=C2=A0 =C2=A0emacs and decrease the font size until the window has= more than 255
=C2=A0 =C2=A0lines. Follow the editing example in (1) abo= ve, and emacs will lock up.

3. You can also reproduce in '-nw= 9; mode on a normal size display by opening
=C2=A0 =C2=A0up a terminal w= indow with a very small font size, enough to have more
=C2=A0 =C2=A0than= 255 vertical lines.

I can reproduce the bug using all of these meth= ods on
these and similar systems:

=C2=A0 =C2=A0Red Hat Enterprise= Linux Server Release 7.3 (Maipo)
=C2=A0 =C2=A0Intel Xeon CPU E5-2667 V3=
=C2=A0 =C2=A0GNU Emacs 24.3.1
=C2=A0 =C2=A0GNU Emacs 27.0.50 (built = from master)

=C2=A0 =C2=A0macOS Mojave
=C2=A0 =C2=A02013 MacBook = Pro
=C2=A0 =C2=A0Intel Core i7
=C2=A0 =C2=A0GNU Emacs 25.3.1

C= ause of unsigned char overflow:

struct matrix_elt, used by do_direct= _scrolling, in scroll.c, has three fields
that are declared as unsigned = char. It looks like they were previously
declared as signed char, then c= hanged to unsigned char, perhaps to fix a
previous incarnation of this o= verflow.

The fields in question are 'insertcount', 'dele= tecount' and 'writecount'.

The patch below changes these= fields to 'int'. The alloction of 'matrix_elt'
is a sma= ll memory footprint
(see allocation in scroll.c function 'scrolling_= 1')
I can't see a justification for keeping these fields 'un= signed char'.

On most systems, it is actually a challenge to cre= ate an emacs window larger
than 255 lines, which is why I'm guessing= this overflow hasn't come up before
(I couldn't find bug report= mentioning it). However, on a system with a 4k
display in portrait mode= , it is pretty easy to accidentally create a window
this large.

<= div>For example, if I am using a tmux display with reasonably-sized pane on= a
4k monitor in portrait mode, and I happen to zoom the tmux pan= e to full
screen, the emacs window will now be larger than 255 li= nes, emacs will enter
an infinite loop, and the process will need= to be killed.

The overflow was confirmed by attaching to a crashe= d/looping emacs
process with gdb, and stepping through the code, on diff= erent operating
systems and machines.

Changelog:

2018-10-= 05 =C2=A0 Scott Corley <scott@scorl= ey.com>
* scroll.c (struct matrix_elt): change unsigned char fie= lds to int
=C2=A0 fixes overflow lockup crash with window sizes &= gt; 255 lines.

Here is the patch:

---
=C2=A0src/scr= oll.c | 6 +++---
=C2=A01 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/scroll.c b/src/scroll.c
index a29f2d37f5..240005b= 4e3 100644
--- a/src/scroll.c
+++ b/src/scroll.c
@@ -41,13 +41,13 = @@ struct matrix_elt
=C2=A0 =C2=A0 =C2=A0int deletecost;
=C2=A0 =C2= =A0 =C2=A0/* Number of inserts so far in this run of inserts,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 for the cost in insertcost. =C2=A0*/
- =C2=A0 =C2=A0un= signed char insertcount;
+ =C2=A0 =C2=A0int insertcount;
=C2=A0 =C2= =A0 =C2=A0/* Number of deletes so far in this run of deletes,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 for the cost in deletecost. =C2=A0*/
- =C2=A0 =C2=A0un= signed char deletecount;
+ =C2=A0 =C2=A0int deletecount;
=C2=A0 =C2= =A0 =C2=A0/* Number of writes so far since the last insert
=C2=A0 =C2=A0= =C2=A0 =C2=A0 or delete for the cost in writecost. */
- =C2=A0 =C2=A0un= signed char writecount;
+ =C2=A0 =C2=A0int writecount;
=C2=A0 =C2=A0}= ;

=C2=A0static void do_direct_scrolling (struct frame *,
--
Thanks,
Scott
--0000000000005bacb20577862c62--