From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#32463: 27.0.50; (logior -1) => 4611686018427387903 Date: Sun, 19 Aug 2018 11:32:19 +0000 Message-ID: References: <5230a57b-5896-606d-f157-2e547710b6e8@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1534678328 7530 195.159.176.226 (19 Aug 2018 11:32:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Aug 2018 11:32:08 +0000 (UTC) Cc: andrewjmoreton@gmail.com, 32463@debbugs.gnu.org To: eggert@cs.ucla.edu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 19 13:32:03 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 1frLwB-0001qD-4a for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Aug 2018 13:32:03 +0200 Original-Received: from localhost ([::1]:42465 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frLyH-0006Ul-Pf for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Aug 2018 07:34:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frLyB-0006Ud-MA for bug-gnu-emacs@gnu.org; Sun, 19 Aug 2018 07:34:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frLy6-0002Vv-RS for bug-gnu-emacs@gnu.org; Sun, 19 Aug 2018 07:34:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49418) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1frLy6-0002Vm-Mc for bug-gnu-emacs@gnu.org; Sun, 19 Aug 2018 07:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1frLy6-0004ME-En for bug-gnu-emacs@gnu.org; Sun, 19 Aug 2018 07:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Aug 2018 11:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32463 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32463-submit@debbugs.gnu.org id=B32463.153467838516684 (code B ref 32463); Sun, 19 Aug 2018 11:34:02 +0000 Original-Received: (at 32463) by debbugs.gnu.org; 19 Aug 2018 11:33:05 +0000 Original-Received: from localhost ([127.0.0.1]:54436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1frLxB-0004L2-56 for submit@debbugs.gnu.org; Sun, 19 Aug 2018 07:33:05 -0400 Original-Received: from mail-lj1-f176.google.com ([209.85.208.176]:44734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1frLx9-0004KX-GT for 32463@debbugs.gnu.org; Sun, 19 Aug 2018 07:33:04 -0400 Original-Received: by mail-lj1-f176.google.com with SMTP id q127-v6so9495924ljq.11 for <32463@debbugs.gnu.org>; Sun, 19 Aug 2018 04:33:03 -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=OnMiCO497Fw9mRu3QEaHBZ6+JKK8Ih4ofQesgP/RheI=; b=s+UzPaI/MPqFZDYZmEcZk4WUgXQaZffBxnsf9YSN+MYzo5XCgcrUdVu8hEOFQTdusB 7pu5NYMgaiYgfybOCdZ9Ws59kNedlcRPndBqRkZ4o68zocLZfDC+yRIyXaIkMaRfmTYR ynpTFujs2Sbgl9PRisefbb/PGSNnQLZydc609T5bxpgAe3jt2qdVOi/lJKPQlu8AXGpp x2HOT0xNNI97bVKrNItWi9jYvNu2nQVLvHKJWW2ZE1qW+OhcE5Zys4HXXGp45i2gQrYt c8wPxCcKL/meviFk9wApzxehPBKYjLGzER6wgeNp6HjikvQfPi0tL68ELkGksZKIo2X5 lnwA== 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=OnMiCO497Fw9mRu3QEaHBZ6+JKK8Ih4ofQesgP/RheI=; b=tTyecatUhbORXlEVrGQLPaUOzSkvpmL7Q1/3CR5FpJvJtzRHC/OM4Ur4jUwBTfRcjE cckszUstrVkU/LfpIqJizidkRtPx+VmDtFY0LyZihNbYJmtl2/QAHxE5/xtikpMivG8b I25qv7DdPjKxqVAa6VIMMhTNw2k9tatO3+5QrVduFixFMST5mSNJDZW3rmpnIFqAu2rj zHLH1rIn5w3ISLGSsGLMXdxTpICZz3ZqHLPJQ8/Ws2VvncQUXANouT04HgdaICcdtlJX XhpXeQgEON47g1kBealDCYokzkDkYIy1jyCtZp3YCaqa8jyJQjK6FhNoTuB5LQnlQdHN qxPg== X-Gm-Message-State: AOUpUlHx/S2AKHrAKwbujcEYfzSguB7lJ928Qn13/9Wo1UJ008oT71oZ 75FnHuMhPepyusH+t+753jM35LdFb6FjTktGy70= X-Google-Smtp-Source: AA+uWPxEv8+NzNtKsp82GiPOjcz0tMTlTczVcI8xmE8f2lFD6bhHlunJ3Thn/jPy2069ma+Yd6JK5d5fUR1cwzdgS1s= X-Received: by 2002:a2e:712:: with SMTP id 18-v6mr30446243ljh.101.1534678377736; Sun, 19 Aug 2018 04:32:57 -0700 (PDT) In-Reply-To: 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:149592 Archived-At: On Sun, Aug 19, 2018 at 10:59 AM Paul Eggert wrote: > Pip Cet wrote: > > Even if memory isn't exhausted, creating a bignum larger than 16 GB > > (our most-positive-bignum) results in an immediate crash with external > > libgmp (Linux, x86_64), and that appears not to be easy to fix without > > modifying gmp. > > Is there a libgmp bug report for this? or is there a reasonable way to > characterize this arbitrary limitation in libgmp, so that Emacs does not go over > the limit and crash? I've already put in one limit, and we can tighten that > limit (or add more checks) if we know what libgmp's limits are. libgmp stores mpzs as an int (this is a known bug, and plans to work around it are on the GMP site) giving their current size in words (8 bytes each on x86_64). So the maximum bignum is 0x7fffffff * 64 one bits. When that limit is reached, _mpz_realloc calls abort rather than the user-provided reallocation function. Of course, on POSIX systems, we can catch SIGABRT, but then we'd need a flag to mark whether we're in a GMP function and another flag to mark that we're calling abort from a signal handler which might have interrupted the GMP function, and a third flag to mark that stack overflow occurred in a signal handler which interrupted a GMP function so we longjmp()ed out of GMP. On most ELF systems, we can probably preload a library redirecting abort() for GMP. These are all ugly solutions to what is ultimately a GMP limitation that should probably be fixed, making GMP interruptible and abort-safe, which essentially all interactive applications of it require. I think we can be clever and wrap calls to mpz_mul_2exp (which can create arbitrary bignums) and whatever Fexpt uses and make our allocation function signal for bignums >= sqrt(most-positive-bignum) (such numbers cannot produce the overflow condition if combined with multiplication, addition, or subtraction). In fact, I'd suggest a much lower limit until/unless the C-g issue is fixed, perhaps overridable by a user preference if people really want to use big bignums. (I've looked at implementing big rational numbers as an Emacs type using GMP, too, and I think performance issues are more pronounced for those, since even (absolutely) small numbers can have a huge representation.) > > That and left shifts are probably the ones to worry about for now. > > Creating a large bignum by repeated multiplication will require at > > least some intermediate bignums, which need to be allocated and copied > > and thus probably alert the user to something going on. > > expt does bignums now too, so that's one more point of failure in this area. Yes, that's what "that" referred to. Are there other operations that create large bignums that I've missed? I'm not sure what a reasonable limit would be, but I think a global limit of bignum size to something that allows for "immediate" computations would be best.