From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#39962: 27.0.90; Crash in Emacs 27.0.90 Date: Fri, 13 Mar 2020 08:39:41 +0000 Message-ID: References: <24162.58107.725366.668639@cochabamba.vanoostrum.org> <329e58b1-6255-311e-bdd8-b6f5b3d5208f@cs.ucla.edu> <22225b66-44f6-d132-3036-92181d53c28d@cs.ucla.edu> <89A83582-358F-43DC-B96E-04EE9D655D5F@vanoostrum.org> <63b88e2d-9888-f3ce-a4b0-fcf344e803e5@cs.ucla.edu> <83d09lbgk5.fsf@gnu.org> <83y2s48yn7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="86796"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 39962@debbugs.gnu.org, pieter-l@vanoostrum.org, eggert@cs.ucla.edu To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 13 09:41:13 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jCfsW-000MT1-DN for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 13 Mar 2020 09:41:12 +0100 Original-Received: from localhost ([::1]:55694 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jCfsV-0008ED-Gk for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 13 Mar 2020 04:41:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52704) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jCfsN-0008E7-Aj for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 04:41:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jCfsM-0000q8-8A for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 04:41:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52139) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jCfsM-0000pB-4o for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 04:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jCfsL-0001jT-Ux for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 04:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Mar 2020 08:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39962 X-GNU-PR-Package: emacs Original-Received: via spool by 39962-submit@debbugs.gnu.org id=B39962.15840888266597 (code B ref 39962); Fri, 13 Mar 2020 08:41:01 +0000 Original-Received: (at 39962) by debbugs.gnu.org; 13 Mar 2020 08:40:26 +0000 Original-Received: from localhost ([127.0.0.1]:58112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jCfrl-0001iL-TN for submit@debbugs.gnu.org; Fri, 13 Mar 2020 04:40:26 -0400 Original-Received: from mail-ot1-f49.google.com ([209.85.210.49]:37624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jCfrj-0001i5-S9 for 39962@debbugs.gnu.org; Fri, 13 Mar 2020 04:40:24 -0400 Original-Received: by mail-ot1-f49.google.com with SMTP id i12so3994264otp.4 for <39962@debbugs.gnu.org>; Fri, 13 Mar 2020 01:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5bAj0RaPV/eTxdj+a+Nncv4sac4703pmV0efYkyGbOY=; b=Zqm7g8Y7SGDsmJxzqpN4uHIdBR3k4GT2zqVBGFsf69r/YJu+Tp4iPgwR4M6LMYPnX+ 2eQEiVb6Qcf09fClH0NkjIf/I2eh5icuGsI1T775uwET+Xq2yeqYs57aD63VrYgBmyJI HGOvuGEqOruTxKztTNiLtn/ARi3X4jriQ7enmm1jkebQGBAjYi8412HX4dLcfkKZPNL1 gSxf7PYekCpJlrNR9VG179iybfV/0D2adNfX6ZH5+jS5+UOdYDruiB+Su16yhakAq87D oKKLIt5n/OWCaQ0bzfi/izn3HHSzE6xPRncM1qTeLGvaHje1dWL2QMjfMW2eiWZRcL6x sqFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5bAj0RaPV/eTxdj+a+Nncv4sac4703pmV0efYkyGbOY=; b=IOchAiHRXlLmjUM1DP9vP6wA8fJknAyd1aqh7eOUM4aAMkcwZ73yllocbpBmcwkjFr rAeGx1Ap3qpDeC8Ib5Lk31m8ILHV2Zm0vGmaUn4CN7fEZPunBULmA9N1HP1LTh4fwq4x z7WCuxbfRkRXny07deTVntiqgd/7Ymt2e1/FIokyuMy/J3AJE24CaIFzYmI+uyLNM5H+ kI8TSCI5CzWI317AJEXJmrV3UL3gX5sfQPeTRc3igNF8Ta/vXngNsHFx7tO2yZ1ySxx+ TwF8RkNqzfdTWFBOhqnxvomwP6nXYZbKfbVlnfHrDmkrV/lPLsfuWD50PLtKbnzEfCiZ oC1A== X-Gm-Message-State: ANhLgQ2dYNNJYdBiKAxL3mFMQ8e5RI7L17xWyKJCZ3BC3lMOu5nRm3At M+aRMVDaQmtuKvDe6PppCtMg2IrLfoT+sJHuHqk= X-Google-Smtp-Source: ADFU+vv4itW97S8ImbaKhgzbY+fB419luC/4VwK3ezTug3POt+bxHzZimT3BDrxnEN2TqlMlY3Gp034AJdzHMCtgBus= X-Received: by 2002:a05:6830:11:: with SMTP id c17mr9498035otp.292.1584088818125; Fri, 13 Mar 2020 01:40:18 -0700 (PDT) In-Reply-To: <83y2s48yn7.fsf@gnu.org> 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: 209.51.188.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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:177253 Archived-At: On Fri, Mar 13, 2020 at 8:08 AM Eli Zaretskii wrote: > > The first attachment to this message is an Elisp file which does the > > same thing, by creating thousands of symbols. On GNU/Linux, with > > fairly default standard stack size settings, I get a segfault after > > some 85,000 symbols have been created. > > The default stack size on GNU/Linux is 2MB, right? Maybe it's high > time we raised that, what with the memory size today's machines > routinely have at their disposal. Well, it's just virtual memory, so raising it shouldn't be a problem, though apparently the stack size is limited to 4 GB. > FWIW, the MS-Windows build have > been using a 8MB run-time stack for a very long time. "ulimit -s" produces 9788 here. > Of course, given enough recursive data structures we can always crash > the current GC the way it is implemented. Absolutely. > But the question is how > many such recursive symbols are there in Pieter's sessions? are they > anywhere near the 1000000000 mark you used in your test program? If I'm reading the code correctly, the recursion depth is equal to the number of messages in VM's list, so a few tens of thousands of symbols seem possible. Not anywhere near a billion, though. > IOW, > I think we need to know how close we are in real-life sessions to the > dangerous mark. It should certainly be possible to warn the user when stack usage during GC exceeded a given percentage of the possible stack size; hopefully, that would happen at least once before a crash. It would also be possible to modify the code in sysdep.c to report when it has detected an unrecoverable stack overflow. > Maybe this is also worth reporting to VM developers. They might > consider changing their implementation to avoid these problems. I think this is a VM-specific problem, not anything that we should be changing GC code on the release branch for. Do you happen to know whether anyone is looking at gcc -fsplit-stack support for Emacs? That would avoid the problem entirely but allow us to keep our current GC code.