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#32338: 26.1; term.el broken on macOS Date: Wed, 03 Oct 2018 17:59:14 +0300 Message-ID: <83k1mz2i0t.fsf@gnu.org> References: <87k1nhoyji.fsf@gmail.com> <87bm8rpu0x.fsf@gmail.com> <87o9cpnpry.fsf@gmail.com> <838t3sdb29.fsf@gnu.org> <83bm8f5xuq.fsf@gnu.org> <83k1n252ns.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1538578693 28562 195.159.176.226 (3 Oct 2018 14:58:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 3 Oct 2018 14:58:13 +0000 (UTC) Cc: 32338@debbugs.gnu.org, alan@idiocy.org, npostavs@gmail.com To: Constantine Vetoshev Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 03 16:58:08 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 1g7ibI-0007J1-CU for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Oct 2018 16:58:08 +0200 Original-Received: from localhost ([::1]:49188 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g7idO-0000DR-WB for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Oct 2018 11:00:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45211) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g7idC-0008W7-8P for bug-gnu-emacs@gnu.org; Wed, 03 Oct 2018 11:00:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g7id9-0007tw-26 for bug-gnu-emacs@gnu.org; Wed, 03 Oct 2018 11:00:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59730) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g7id8-0007tM-UD for bug-gnu-emacs@gnu.org; Wed, 03 Oct 2018 11:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g7id8-0002Jd-QN for bug-gnu-emacs@gnu.org; Wed, 03 Oct 2018 11:00: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, 03 Oct 2018 15:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32338 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32338-submit@debbugs.gnu.org id=B32338.15385787718831 (code B ref 32338); Wed, 03 Oct 2018 15:00:02 +0000 Original-Received: (at 32338) by debbugs.gnu.org; 3 Oct 2018 14:59:31 +0000 Original-Received: from localhost ([127.0.0.1]:35755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g7icc-0002IL-TX for submit@debbugs.gnu.org; Wed, 03 Oct 2018 10:59:31 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35427) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g7icb-0002I8-HZ for 32338@debbugs.gnu.org; Wed, 03 Oct 2018 10:59:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g7icT-0007QD-0N for 32338@debbugs.gnu.org; Wed, 03 Oct 2018 10:59:24 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g7icR-0007Pi-Jz; Wed, 03 Oct 2018 10:59:20 -0400 Original-Received: from [176.228.60.248] (port=1656 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g7icQ-0006hV-AC; Wed, 03 Oct 2018 10:59:19 -0400 In-reply-to: (message from Constantine Vetoshev on Tue, 2 Oct 2018 15:51:11 -0700) 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:150912 Archived-At: > From: Constantine Vetoshev > Date: Tue, 2 Oct 2018 15:51:11 -0700 > Cc: Alan Third , Noam Postavsky , 32338@debbugs.gnu.org > > One change from my past reports: after compiling Emacs with -g flags, > I have now managed to reproduce the crash under lldb, including > attaching to the forked process which eats CPU after the crash. > Backtrace from that process is attached. Great, thanks. > The highlights (as far as I noticed) are: > - emacs_re_max_failures and the older re_max_failures are not > initialized at this point I believe this is incorrect. re_max_failures is statically assigned a value of 40000 in regex-emacs.c, and should be initialized at link time. Your build is with optimizations, isn't it? I think the optimizer reordered instructions, which creates the illusion that re_max_failures has a garbled value at that point. The value of newlim, 10022912, is correct, you can confirm that by calculating it by hand assuming that re_max_failures is 40000 and using the other values your debugging session shows. > - in the working branch, newlim is reset to rlim.rlim_max; in the > broken branch, it is not > - in the working branch, setrlimit does not get called; in the broken > branch, it does Right. > I'm guessing the problem is with the uninitialized values for > *_re_max_failures and the resulting values being assigned to lim and > newlim. It seems to only work on the working branch by accident > because, for whatever reason, newlim always gets reset to > rlim.rlim_max and setrlimit doesn't get called. No, I think the problem is with this line: > 884 if (pagesize <= newlim - lim) In your case newlim is smaller than lim, but rlim_t is an unsigned data type on your system, so the subtraction wraps around and produces a large positive value, which then tricks Emacs into thinking it needs to enlarge the stack, whereas in reality the stack space already available, 67MB, is large enough. (Btw, that value sounds too large, I wonder if it's some problem with getrlimit on your system.) So please try the patch below with the emacs-26 branch, and see if the problem goes away. diff --git a/src/emacs.c b/src/emacs.c index 483e848..c0b4bd9 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -875,7 +875,8 @@ main (int argc, char **argv) newlim = rlim.rlim_max; newlim -= newlim % pagesize; - if (pagesize <= newlim - lim) + if (newlim > lim /* in case rlim_t is an unsigned type */ + && pagesize <= newlim - lim) { rlim.rlim_cur = newlim; if (setrlimit (RLIMIT_STACK, &rlim) == 0) @@ -884,9 +885,9 @@ main (int argc, char **argv) } /* If the stack is big enough, let regex.c more of it before falling back to heap allocation. */ - emacs_re_safe_alloca = max - (min (lim - extra, SIZE_MAX) * (min_ratio / ratio), - MAX_ALLOCA); + emacs_re_safe_alloca = + max (min (min (0, lim - extra), SIZE_MAX) * (min_ratio / ratio), + MAX_ALLOCA); } #endif /* HAVE_SETRLIMIT and RLIMIT_STACK and not CYGWIN */