From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Oct 2016 03:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 24751@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.147702203517794 (code B ref -1); Fri, 21 Oct 2016 03:54:01 +0000 Received: (at submit) by debbugs.gnu.org; 21 Oct 2016 03:53:55 +0000 Received: from localhost ([127.0.0.1]:42774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bxQu2-0004cv-2O for submit@debbugs.gnu.org; Thu, 20 Oct 2016 23:53:55 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bxQtz-0004ce-Nv for submit@debbugs.gnu.org; Thu, 20 Oct 2016 23:53:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxQtp-0007Tz-Ay for submit@debbugs.gnu.org; Thu, 20 Oct 2016 23:53:46 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:45668) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bxQtp-0007Tt-7O for submit@debbugs.gnu.org; Thu, 20 Oct 2016 23:53:41 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxQtj-0000gH-OM for bug-gnu-emacs@gnu.org; Thu, 20 Oct 2016 23:53:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxQte-0007OI-OU for bug-gnu-emacs@gnu.org; Thu, 20 Oct 2016 23:53:35 -0400 Received: from mail-it0-x231.google.com ([2607:f8b0:4001:c0b::231]:37879) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bxQte-0007Nw-Ea for bug-gnu-emacs@gnu.org; Thu, 20 Oct 2016 23:53:30 -0400 Received: by mail-it0-x231.google.com with SMTP id m138so138242686itm.0 for ; Thu, 20 Oct 2016 20:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:user-agent:mime-version; bh=h94LuU7lhbORh/kI7YTJqOXPQVqGvOKeVBHK1bKGVX4=; b=tZUcLBDkl2t6VW0/8VXyc5jsumDZIQbExqB+Rmj3u/OBIsLHM5RU1clZb6l9n3c0IY vEuZXIxkOdvlNoxBBF0OlDMm99jfALIvmkIbdsrDkCMs2r7Tdlk9iA3qI2Ty0si+d9U9 sHFP4LrBRJQAJMN6G1do6ofCahvsu98mmNXDaWGFsh4gBWGSwnAkcOlhg110L9t09az5 VgXRzY96w2X0S/PVnWaJQM7ADn9XaLSR1/Md50LPUFIXETBGSTy0NxtFjlWtEu/grFlw I2U8EHe3gMcG9W825o0Xz2OmFhek3t4jmUsh6VAgmGp2pGR+R+kjM4rReauF0Lkrwkka LECw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:subject:date:message-id :user-agent:mime-version; bh=h94LuU7lhbORh/kI7YTJqOXPQVqGvOKeVBHK1bKGVX4=; b=HhcexDCyDwJnsuPaELYGH0+2uzV8rUo7Aba+Cz2i9Dftd90moq/J+op37LpNI9tNGS OMpkb3zFT31bqVvgsPalmr5nMhUQ4Qop9cmgNGjWuOzx1ZEfH98IhEMK84YLJpOsLeBP y/V9QVxsFU+ACSYnBxkb+cRp7benQv+kWXIGKdIfbGCxRTvAEkA7Gz0ZZncI8NyAZjuS hkjsOx5dcSKdFOfLvnVqKMd5y8DjK8C+qWfBJLtMqRIZP6DmzmM00325DzZ0jCNfPBM5 7kYFpEJjiie3FsnLZkgP9wPHYIGiAxTEn+Zfkcb4S4jYeyvsY7XFJsunK5mFVlFGmTLf dDtQ== X-Gm-Message-State: ABUngvcFtzX2RfAJZLj8HqBArnLeRZ8gGNdhmsJWPaFtbGesVpyXwe7HbxiHsTVNl8RptA== X-Received: by 10.107.155.14 with SMTP id d14mr4654912ioe.64.1477022009537; Thu, 20 Oct 2016 20:53:29 -0700 (PDT) Received: from zony ([45.2.7.130]) by smtp.googlemail.com with ESMTPSA id z23sm7060237ita.1.2016.10.20.20.53.28 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 20 Oct 2016 20:53:29 -0700 (PDT) From: npostavs@users.sourceforge.net Date: Thu, 20 Oct 2016 23:54:05 -0400 Message-ID: <87twc6tl0i.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --=-=-= Content-Type: text/plain This is a followup from Bug #24358, since that thread filled up with messages about the crash in 25.1, so I'm opening a new bug for the wrong regex stack overflow check (this affects only the master branch). To reproduce the error run (re-search-forward ".*\\(\n.*\\)*" nil t) in a buffer with contents of the attached bug-24358-regex-max-specpdl.txt. --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename=bug-24358-regex-max-specpdl.txt Content-Transfer-Encoding: quoted-printable Content-Description: sample data for regex test DESCRIPTION;LANGUAGE=3Den-US:Nn Nnnnn\,\n\nNnnnnnnnn nnn nnn nnnnnn nn nnnn= nn nnnnnnn nnnn nnnnnnnnn. N nnnn nnnnnnnnn nn nnn nnnnnnnn nnnnnnn nnn nn nn nn nn-nnnnnnn nn Nnnnnnn nn 99.99 NNNN\n\nNnnn nnnnnnn\,\n\nNnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n\nNNN Nnnnnn Nnnnnnn\nNnnn Nnnnn Nnnn n\,\n99 Nnnnnnnnnn Nnnnnn\,\nNnnnnn\, NN9N 9NN\n+999999999999 | Nnnn: nnnn nnnnn@nnn.nnn\nnnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n\n\n\n\n__________________ ___________________________\nNnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnn nn.nn]\nNnnn: 99 Nnnnnn 9999 9:99 NN\nNn: NNN Nnnnnn \n Nn: Nnnn Nnnnn \; Nnnn Nnnnnnnn \; +NNN N \; +NN Nnnnnn \nNnnnnnn: Nn: [NNN] Nn: N nnnnnn nnnnnnn nn NNN\n\n\nNnnnn\, N nnnn'n nnn nnn nnnn nnnnn nnn. 99:99 NNN nnn nnnnnn\, nnn 99:99 NNN nn nnnnnn nn nn n nnnnnn\, nnn N'n nnnnn n nnnnnnnn. :)\n\n--\nNnn/Nnnnnnn\nNnnnn N. Nnnnnnnnnnn\nNnnnnnnn Nnnn NN\n\ nNn Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n\n> Nn Nnnnn\,\n>\n> N nnn nnn'nn nnnnnn n nnnn nnnn.\n>\n> Nnnnn nn nn nnnnnnnn nn nnnn Nnnnnnnn nnnnn nnnn nnnn nn nnnn nn 9.99nn NNN nnnnn?\n>\n> Nnnn nnnnnnn\,\n>\n> Nn nnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>\n> NNN Nnnnnn Nnnnnnn\n > Nnnn Nnnnn Nnnnn\,\n> 99 Nnnnnnnnnn Nnnnnn\,\n> Nnnnnn\, NN9N 9NN\n> +99 9999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n> nnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n> \n> -----Nnnnnnnn Nnnnnnn-----\n> Nnnn: NNN Nnnnnn\n> Nnnn: 99 Nnnnnn 9999 9:99 NN\n> Nn: 'Nnnnn N. Nnnnnnnnnnn' \; NNN Nnnnnn\n> < NNNNnnnnn@nnn.nnn>\n> Nn: Nnnn Nnnnn \; Nnnn Nnnnnnnn \;\n> +NNNN \; +NN Nnnnnn \ n> Nnnnnnn: NN: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>\n> NN Nnnnn\,\n>\n> Nn nnnnnnn nnnnn nnn nn. Nnnnnn 9nn NNN nnnnn nn nnnnn. N nnnn nnnn nnn.\n>\n > N=E2=80=99nn nnnnnnn nnn n nnnnnnn nnnnnn nnn nnnn nnnnnnnn nnnnnnn.\n>\= n> Nnn n nnnnnnn\,\n>\n> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>\n>= =20 NNN Nnnnnn Nnnnnnn\n> Nnnn Nnnnn Nnnnn\,\n> 99 Nnnnnnnnnn Nnnnnn\,\n> Nnnn nn\, NN9N 9NN\n> +999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n> nnnnnnnnn@nnn. nnn | nnn.nnn.nnn\n>\n> -----Nnnnnnnn Nnnnnnn-----\n> Nnnn: Nnnnn N. Nnnnn nnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n> Nnnn: 99 Nnnnnn 9999 9:99 NN\n> Nn: NNN Nnnnnn \n> Nn: Nnnn Nnnnn \; Nnnn Nnnn nnnn \;\n> +NNNN \; +NN Nnnnnn \n> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>\n> Nn\, Nnnnn .\n>\n> Nnnnnn nnnnnnn Nnnnnnnnn nnnn nnnn nn nnnn nnn nn\, nnnnnnnnn nn n nnn\n> nnnn nn nnnn nnnnn nnn nnnn nnnnn. Nn nn nnnn nn nnnn nnnnn NN nnn nn\,\n> nn nnn nn nn nnn nnnnn nnn nnnn? Nnnnnnn nnnnn 99 NNN nnnnn nnn n n.\n>\n> Nnnnnn N nnnn nnn nn nnnn nnn nnnn nn? Nn nnnnnn nnnn nn +99 999 9 9999.\n>\n> --\n> Nnn/Nnnnnnn\n> Nnnnn N. Nnnnnnnnnnn\n> Nnnnnnnn Nnnn N N\n>\n> Nn Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n>\n>> Nn Nnnnn\ ,\n>>\n>> Nnnnn\, nnnn nnnnnnn nnn nnnn nnnnnnnnnnnn nn nnn nnnn. Nnnn nn= =20 nnn nnnnnnn nnnn nnnnnn nn nnnn nn nnnnnn nnnnnnnnn nnn NNN nnnnnnnnn.\n>> \n>> Nn nnnnn nn nnnn nn nnnn nnnn nnnnnnnnn nnnn nnn nnnnnnnnnnnnn nnnnnn \n>> nnnnn N nnnn nnnnnnnn. N nnnnn nnnnnn nn nnnnn nnn nnnnnnnn nnnnn\,\n >> nnnn nnnn / nnnnnnnnnn nnnnnnnnn nnn nnnn nnnnnn nnnnnnnnn nnn nnn\n>>= =20 nnnnnn / nnnnnnn / nnnnnn nnnnnnnnnnnnn\, nnnnnnnn nnnnn nnnnnn 99\n>> nnn nnnn nnnn n nnnnn nnnn. Nnnn nn nnnn nnnnn nnnnnn nnn nn nnn nnnnn\n>> nnn nnnn nnnn nnnnnnnnnn.\n>>\n>> Nnnnnn nnn nn nnnn nnnn nnnnnnnnnn nnnn / nn nnn nnn nnn.\n>>\n>> Nnnn nnnnnnn\,\n>>\n>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nn nnnnnn Nnnnn Nnnnnn\n>>\n>> NNN Nnnnnn Nnnnnnn\n>> Nnnn Nnnnn Nnnnn\,\n>>= =20 99 Nnnnnnnnnn Nnnnnn\,\n>> Nnnnnn\, NN9N 9NN\n>> +999999999999 | Nnnn: nnn nnnnnn@nnn.nnn\n>> nnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n>>\n>> -----Nnnnnnnn N nnnnnn-----\n>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>> Nn nn: 99 Nnnnnn 9999 9:99 NN\n>> Nn: NNN Nnnnnn \n>> Nn:= =20 Nnnn Nnnnn \; Nnnn Nnnnnnnn \;\n>> +NNN N \; +NN Nnnnnn \n>> Nnnnnnn: Nn: [NNN] Nn : Nnnnnnn nnnnnnn nn NNN\n>>\n>> Nnnnn nnnnn.\n>>\n>> N nnnn nnn nnnnnn nn nn nnnn\, nnn N'n nnnnnn nnnnn nnnn nnnnnn nn nn\n>> nnn. N nnnnn nn nnn= =20 nnnnn nnnnn nn nnn nnnnn nnnnnnnnn nnnn-nnn-nnnn\n>> nnn nnnn-nn-nnnn nnnn nn. Nnn nn nnnnnnn nn nnn nnnnn nnnnn nnnnn?\n>> Nnn nnnn-nnn-nnnn\, nnn= =20 nnnnnnnn nnnnnn nnnnnnn nn n nnnnnn\, nnnnn N\n>> nnn nnnnnnnnn n nnnnnn.= =20 Nn nnnn nnnnnnn nn nnn nnn nnnnnnnnnn nnn\n>> nnnn nnnn nn nnnnn\, nn nnn nnnn nnnn nn nnn nnnn nnnnnn nnnnn?\n>>\n>> Nnnnnn nnn nn nnnn nn nn\, nn= =20 nnnn nnnnnnnn nnn nnnn nnnnn nnnnn nn\n>> nnnnnn nn nnnnnnnnnn nnn nnn nnn nnnnnnn nnnnnn nnnn nn nnn nnnnn\n>> nnnn\, nnn nn nnnnn nn nnnn nn nnnn n nn nnnnnnn nnn nnnnnnnnnn.\n>>\n>> N nnnn nnnnnnnnnnnn nnnnnn nnnnnn nnnnn n\, nnnnn nnnnnn\, nnnnnnnnn\n>> nnnnn nnnnnnn nnn nnnnnn nnnnnnn\, NNN nn nnnn\, nnnnnnnnn nnnnnnnn\n>> nnnnnnnnnn\, nnn nnnnn nnnnnnnnnnnnn.\n>>\n> > Nnn nn nn nnnnnnn nn nnnnnnnnnn? Nn nn nnnn nn nnnn nnnn nnnnnn nnnn nn nnnnnnn nn nnn?\n>>\n>> --\n>> Nnn/Nnnnnnn\n>> Nnnnn N. Nnnnnnnnnnn\n>> Nn nnnnnn Nnnn NN\n>>\n>> Nn Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n >>\n>>> Nn Nnnnn\,\n>>>\n>>> Nnnnn - N nnnn nnnn nnnn nnnnn nnnnnnnnnn nn= =20 nnn nnn nnnnnn nn nnn nnn nnnnnnnnnnn.\n>>>\n>>> Nnnnnn nnnnnnnn nnnnnnn.\ n>>>\n>>> Nnnn nnnnnnn\,\n>>>\n>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nn nnn Nnnnnn\n>>>\n>>> NNN Nnnnnn Nnnnnnn\n>>> Nnnn Nnnnn Nnnnn\,\n>>> 99 Nn nnnnnnnn Nnnnnn\,\n>>> Nnnnnn\, NN9N 9NN\n>>> +999999999999 | Nnnn: nnnnnn nnn@nnn.nnn\n>>> nnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n>>>\n>>> -----Nnnnnnnn N nnnnnn-----\n>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>= =20 Nnnn: 99 Nnnn 9999 9:99 NN\n>>> Nn: NNN Nnnnnn \n>>> Nn : Nnnn Nnnnn \; Nnnn Nnnnnnnn \;\n>>> + NNNN \; +NN Nnnnnn \n>>> Nnnnnnn: Nn: [NNN ] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>\n>>> Nn\, Nnnnn\n>>>\n>>> Nn nnnn nnnnnn nnn nnnn nnnn NN nnnn. Nnnnn nnn nnnn n nnn nnnnn\n>>> nnnn nnnnn nnnnnnn n NN nnnn nnnnnnn nnn nn nnnn\, nn nn nnnnn nn nnnn\n>>> nn nnnn nnnn nnnn nn nnnn\, nnn nn'n nnn n nnnnnnnn.\n>>>\n>>> N nnn'n nnnnnnnn nnnn nn nnn= =20 nnnn nnnnnnn nnn nnn nn nnnn\, nnn nnnnnnnnnn nn nnn nnnnn nnn nnnn NNN nn nnnnnnnnnnn nn nn nnn nnnnn nnn.\n>>>\n>>> --\n>>> Nnn/Nnnnnnn\n>>> Nnnnn= =20 N. Nnnnnnnnnnn\n>>> Nnnnnnnn Nnnn NN\n>>>\n>>> Nn Nnn\, Nnn 99 9999 nn 99: 99\, NNN Nnnnnn nnnnn:\n>>>\n>>>> Nn Nnnnn\,\n>>>>\n>>>> Nnnn nnn'nn nnn n nnnn nnnnnnn.\n>>>>\n>>>> Nn nn nn nnnnnnn nnnnnnnnn\, nnnnn N nnn nnnnnn n nn nnnn nnnnnn\n>>>> nnnnnnn. Nnn N nnnnnnn nnnnnnn nnn nnnn nn nnnnnnn= =20 NN nnn NN nnnn\,\n>>>> nn nnn nn nnn nnnnn?\n>>>>\n>>>> Nnnnn nn nnnn nnnn nn\, N nnnn nn nnnnn nnn nnnn nnnnn nnnn nnnnnnnnn nn nnnn nnn nnnnnnnn NN N nnnnnnnnn nnn nn nnn nn nnnn nnnnn.\n>>>>\n>>>> Nnnn nnnnnnn\,\n>>>>\n>> >> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>\n>>>> NNN Nnnnn n Nnnnnnn\n>>>> Nnnn Nnnnn Nnnnn\,\n>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>> Nnnn nn\, NN9N 9NN\n>>>> +999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n>>>> nnnnnnnn n@nnn.nnn | nnn.nnn.nnn\n>>>>\n>>>> -----Nnnnnnnn Nnnnnnn-----\n>>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>> Nnnn: 99 Nnnn 9999 9: 99 NN\n>>>> Nn: NNN Nnnnnn \n>>>> Nn: Nnnn Nnnnn \; Nnnn Nnnnnnnn \;\n>>>> +NNNN \; +NN Nnnnnn \n>>>> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnn nnnn nn NNN\n>>>>\n>>>> Nn\, Nnnnn.\n>>>>\n>>>> Nnnn nnnn nnnnnnnnn :)\n>> >>\n>>>> Nn nnn nnnnnn nnnnnnnnn-nn-nnnnnn nnn/nn nnnn-nnn-nnnn nnnnnn? N \n>>>> nnnnn nnnn nn nnnn\, nnn nnn n nnnnnn nnnnnnnn nnnnn nnn nnnnnnnnn= =20 -\n>>>> nnnn nnnn nnnnnnnn nnnnnnn nnn nnnnn nnnn nnn nnnnnnnnnnnn\, nn\n> >>> nnnnnnn nnnn nnnnn nnn nn nnnnnn?\n>>>>\n>>>> --\n>>>> Nnn/Nnnnnnn\n>> >> Nnnnn N. Nnnnnnnnnnn\n>>>> Nnnnnnnn Nnnn NN\n>>>>\n>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n>>>>\n>>>>> Nn Nnnnn\,\n>>>>>\n>>>>> N nnnnn nnn nnnn nnnnn. N nnnnnn nnnn nn nnnnnn nn nnnnnnnn nn nnn nnnn nnnn nnnnnnn nn nnn nnnnnn nn.\n>>>>>\n>>>>> Nnn nn nnnnn nnnn Nnn\, nnn nn nnn nnnnn nn nn Nnnnnn.\n>>>>>\n>>>>> Nnnn n nnnnn nnnnnnn.\n>>>>>\n>>>>> Nnn nn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>>\n>>>>> NNN Nnnnnn Nn nnnnn\n>>>>> Nnnn Nnnnn Nnnnn\,\n>>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>>> Nnnnn n\, NN9N 9NN\n>>>>> +999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n>>>>> nnnnnnn nn@nnn.nnn | nnn.nnn.nnn\n>>>>>\n>>>>> Nnnnn\n>>>>>\n>>>>> -----Nnnnnnnn N nnnnnn-----\n>>>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>> >>> Nnnn: 99 Nnnn 9999 9:99 NN\n>>>>> Nn: NNN Nnnnnn \n >>>>> Nn: Nnnn Nnnnn \; Nnnn Nnnnnnnn\n>>>>> \;\n>>>>> +NNNN \; +NN Nnnnnn \n>>>> > Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>\n>>>>> Nn\, Nnnnn.\ n>>>>>\n>>>>> Nn nnnnnn nnnnn nnn nnn nnn nn 9999 NN. N nnnnnnnn nnn nnn\ n>>>>> nnnnnnnn nnnnnnn nnnnn\, nnn nnn nnnnnn nn nnn nnnnnnnnn nnnnnn\n>> >>> nnnnnnn. Nn nnn\n>>>>> NnnNnn(99) nnn nn 9. Nnnnn nnnn nn nnnnn nnn= =20 nnnn nnnnn nnnn nnn\n>>>>> nnnnnnn nnnnnnnn nnnnn\, N nnnnn nnnnnn NnnNnn= =20 nn nnnnnn nn 9999\,\n>>>>> nn nn nnn nn nnn nnnnnnnn nnnnnnn.\n>>>>>\n>>>> > Nn nnnn nn nnnnnnnn nn nnn nnnnnnn nnnnnnnnnnn\, nn nnnn nnnn nnnnnnnnn= =20 nn nnn nnnn nn nnnnnnnnnn?\n>>>>>\n>>>>> (Nnnn n nnnn nnnnnnn\, N'n nnnnnn n nnn nnn\, nnnn nnnnnnnn nnnn nn\n>>>>> nnnnnn.)\n>>>>> --\n>>>>> Nnn/Nnn nnnn\n>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>> Nnnnnnnn Nnnn NN\n>>>>>\n>>>>> Nn= =20 Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n>>>>>\n>>>>>> Nn Nnnnn\,\n >>>>>>\n>>>>>> N nnn nnn nnnnn nnnnnnnn. N nnnn nnnnnnnnn nnnn nnn nnnnnnn nnnn nnnn nnnn nn nnnn nnn nnnnnnnnn nnnnnnnnn nnnnnnnnnn nn nnnnn nnn nnn nnnnnn nnnnnnn:\n>>>>>>\n>>>>>> 9 nn 99 =3D=3D=3D nnnnnnnn\n>>>>>> 999 nn = 999 =3D=3D =3D nnnn nnnnnnnn\n>>>>>> 999 nn 9999 =3D=3D=3D nnnnnnn nnnnnnn 999 nnn nn= nn nnnnn nn\n>>>>>> 9999 nn 9999 =3D=3D=3D nnnnnnn nnnnnnn 999 nnn nnnnnn nnnnnnn\n= >>>>>> 9999 nn 9999 =3D=3D=3D nnnnnnn nnnnnnn 999\, 999 \, 999 \, 999 nnn nnnn\n= >>>>>> nnnnnnn\n>>>>>> 9999 nn 9999 =3D=3D=3D nnnnnnn nnnnnnn 999\, 999\, 999\, = 999 nn n nnnnnn\n>>>>>> nnnnnnn Nnnn 9999 =3D=3D=3D nnnnn nnnnn.\n>>>>>>\n>>>>>> = Nn nnn nnnnn nnnn nn nnnnnn nnn nnnnnnnn nn nnnnn nnn nnnnnnnnnn nnnnn nnn nnnnn n nnn nnn nnnnnnnnn nnnnnnnnn nn nnnnnnnnn.\n>>>>>>\n>>>>>> Nnnn nnnnnnn\, \n>>>>>>\n>>>>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>>> \n>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>> Nnnn Nnnnn Nnnnn\,\n>>>>>> 99 Nnnnnnnn nn Nnnnnn\,\n>>>>>> Nnnnnn\, NN9N 9NN\n>>>>>> +999999999999 | Nnnn: nnnnnn nnn@nnn.nnn\n>>>>>> nnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n>>>>>>\n>>>>>> -----N nnnnnnn Nnnnnnn-----\n>>>>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnn nn.nn]\n>>>>>> Nnnn: 99 Nnnn 9999 9:99 NN\n>>>>>> Nn: NNN Nnnnnn \n>>>>>> Nn: Nnnn Nnnnn \; Nnnn Nnnnnnnn\n>>>>>> \;\n>>>>>> +NNNN \; +NN Nnnnnn \n>>>>>> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>\n> >>>>> Nnnnn nnnnn\, Nnnnn.\n>>>>>>\n>>>>>> N nnnn nnnnn nnnnnnnn n nnnn nn nnn nnn nnn nn 99 Nnnn Nnnn. Nnn\n>>>>>> nnnnn nnn nnnnnnnn nnnn nnn nnnn "NnnnnNnnnnn Nnnnnn : NNNNNN\n>>>>>> NNNN nnn nnnnnn nn nnn<". Nnn nn nn nn?\n>>>>>>\n>>>>>> --\n>>>>>> Nnn/Nnnnnnn\n>>>>>> Nnnnn N. Nnnnnnnnnnn\n> >>>>> Nnnnnnnn Nnnn NN\n>>>>>>\n>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n>>>>>>\n>>>>>>> Nn Nnnnn\,\n>>>>>>>\n>>>>>>> Nnnn nnn nnn= =20 n nnnn nnnn nnn. Nnnn nn nnnn nn nn nnn nnnnnnn nnnnnnn nnnnnnNnnNN.\n>>>> >>>\n>>>>>>> Nnnnnn nnn nn nnnn nn N nnn nnnnnn nnnnnn nnnnnnn.\n>>>>>>>\n >>>>>>> Nnnn nnnnnnn\,\n>>>>>>>\n>>>>>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnn nnn Nnnnn Nnnnnn\n>>>>>>>\n>>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>>> Nnnn Nnnnn= =20 Nnnnn\,\n>>>>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>>>>> Nnnnnn\, NN9N 9NN\n>>>>>> > +999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n>>>>>>> nnnnnnnnn@nnn.nnn | nnn .nnn.nnn\n>>>>>>>\n>>>>>>> -----Nnnnnnnn Nnnnnnn-----\n>>>>>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>>>>> Nnnn: 99 Nnnn 9999 9:99= =20 NN\n>>>>>>> Nn: NNN Nnnnnn \n>>>>>>> Nn: Nnnn Nnnnn \; Nnnn Nnnnnnnn\n>>>>>>> \;\n>>>>>>> +NNN N \; +NN Nnnnnn \n>>>>>>> Nnnnnnn: Nn: [NN N] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>>\n>>>>>>> Nn.\n>>>>>>>\n>>>>>>> N'nn nnnn nn nnnnnnn nnn n nnnnnn nn nnnnn.\n>>>>>>>\n>>>>>>> N'n nnnnnnnnn nn nnnnnnnnnn nnnnnn nn nn nnn NNN nnnnnn. Nnn nnnnn nnn\, nn N nnnnnnnnn\,= =20 nn nnn nnnn nnn nnnnnnNnnNN nn nnnnn.\n>>>>>>>\n>>>>>>> N nnnn nnnnn nnnnn nn nnnnnn nnnnnnn.\n>>>>>>>\n>>>>>>> --\n>>>>>>> Nnn/Nnnnnnn\n>>>>>>> Nnnn n N. Nnnnnnnnnnn\n>>>>>>> Nnnnnnnn Nnnn NN\n>>>>>>>\n>>>>>>> Nn Nnn\, Nnn= =20 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n>>>>>>>\n>>>>>>>> Nn Nnnnn\,\n>>>>>> >>\n>>>>>>>> Nnnnn nnn nnnnnnn nn nnnnn nnnnn nnn nn nnnnnn.\n>>>>>>>>\n>> >>>>>> Nnnn nnnnnnn\,\n>>>>>>>>\n>>>>>>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnn nnnn Nnnnn Nnnnnn\n>>>>>>>>\n>>>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>>>> Nnnn Nn nnn Nnnnn\,\n>>>>>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>>>>>> Nnnnnn\, NN9N 9NN\n >>>>>>>> +999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n>>>>>>>> nnnnnnnnn@nnn.n nn | nnn.nnn.nnn\n>>>>>>>>\n>>>>>>>> -----Nnnnnnnn Nnnnnnn-----\n>>>>>>>>= =20 Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>>>>>> Nnnn: 99 Nnn n 9999 9:99 NN\n>>>>>>>> Nn: NNN Nnnnnn \n>>>>>>>> Nn:= =20 Nnnn Nnnnn \; Nnnn Nnnnnnnn\n>>>>>>>> \ ;\n>>>>>>>> +NNNN \; +NN Nnnnnn \n>>>>>>>> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>>>\n>>>>>>>> Nn nnnn n.\n>>>>>>>>\n>>>>>>>> N nnnn nnnnnnnnnnnn\, nnn nn nnnnnnnnn nnnnn nnnn n nn nnnnnn.\n>>>>>>>> Nn nnnnnnn nn nn nnnn nn nn nnn nnnnnn nnn nnnnnnnnnn nnnnnnnn\n>>>>>>>> nn nnnnnnnnn nn nnnnn nnnnnnn. Nn nnnn nnnn nnnn nn n nnnnnnnnn\n>>>>>>>> nn nn nnn?\n>>>>>>>>\n>>>>>>>> N nnnnnn nn nn 999.999. 99.999:9999 nn nnnnnnnnnnnnn 99:99 NNN\,\n>>>>>>>> nnnn nnnnNnn NNNN/NNN n nn nnnnnnNnnNn NNNN. Nn nnnnnnn nnn\n>>>>>>>> nnnnnnNnnNn nnnn nn nn nnnn nn nnn nnnnn nnnnnnnn nnnnnnnn?\n>>>>>>>>\n>>>>>>>> --\n>>>>>>>> Nnn/Nnnn nnn\n>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>>>>> Nnnnnnnn Nnnn NN\n>>>>>>>>\n> >>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, Nnnnn N. Nnnnnnnnnnn nnnnn:\n>>>>> >>>\n>>>>>>>>> Nn\, Nnnnn.\n>>>>>>>>>\n>>>>>>>>> Nnnnn nnn\, N'nn nnn nn n n nnn nnn nnnnn nnnnnnn\, nnnnnn nnnnnnnn.\n>>>>>>>>>\n>>>>>>>>> --\n>>>>> >>>> Nnn/Nnnnnnn\n>>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>>>>>> Nnnnnnnn Nnnn= =20 NN\n>>>>>>>>>\n>>>>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn: \n>>>>>>>>>\n>>>>>>>>>> Nn Nnnnn\,\n>>>>>>>>>>\n>>>>>>>>>> N'nn nnnn nnnnn nn nnn NN nnn nnnnnn nnn nnnnnnn. Nnnnnn\n>>>>>>>>>> nnnnnn 999.999.99.999 . (Nnnn 9999)\n>>>>>>>>>>\n>>>>>>>>>> Nnnn nnnnnnn\,\n>>>>>>>>>>\n>>>>>>>> >> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>>>>>>>\n>>>>>>>> >> NNN Nnnnnn Nnnnnnn\n>>>>>>>>>> Nnnn Nnnnn Nnnnn\,\n>>>>>>>>>> 99 Nnnnnn nnnn Nnnnnn\,\n>>>>>>>>>> Nnnnnn\, NN9N 9NN\n>>>>>>>>>> +999999999999 | Nn nn: nnnnnnnnn@nnn.nnn\n>>>>>>>>>> nnnnnnnnn@nnn.nnn | nnn.nnn.nnn\n>>>>>>> >>>\n>>>>>>>>>> -----Nnnnnnnn Nnnnnnn-----\n>>>>>>>>>> Nnnn: Nnnnn N. Nnnn nnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>>>>>>>> Nnnn: 99 Nnnn 9999 99:99 NN\n >>>>>>>>>> Nn: Nnnn Nnnnn \n>>>>>>>>>> Nn: NNN Nnnnnn \; Nnnn Nnnnnnnn\n>>>>>>>>>> \; +NNNN \; +NN Nnnnnn\n>>>>>>>>>> \n>>>>>>>>>> Nnnnn nn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>>>>>\n>>>>>>>>>> Nnnnnnnnn n\, nnnn nn nnnnnnn nnnn nn nnnnn nnnn nnn. Nnnnnn!\n>>>>>>>>>> --\n>>>>> >>>>> Nnn/Nnnnnnn\n>>>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>>>>>>> Nnnnnnnn Nn nn NN\n>>>>>>>>>>\n>>>>>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, Nnnn Nnnnn n nnnn:\n>>>>>>>>>>\n>>>>>>>>>>> Nnn\, n nnnnnnnnn nnnnnn nnnn nnnnnn nn nnn nnnnnnnnnnnn nn nnn nnnnn nnnnnnnnnn nn nnn nnnnnn nnnn. Nn nnnn nnn nnn' n nnnnnn nn nn nnnnnn?\n>>>>>>>>>>>\n>>>>>>>>>>> Nnnnnnn\,\n>>>>>>>>>>>\n> >>>>>>>>>> Nnnn Nnnnn\n>>>>>>>>>>>\n>>>>>>>>>>> N: +99 (9)99 9999 9999 | N : +99 (9)99 9999 9999\n>>>>>>>>>>>\n>>>>>>>>>>> -----Nnnnnnnn Nnnnnnn----- \n>>>>>>>>>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>>>>> >>>> Nnnn: Nnnnnnnn\, Nnnn 9\, 9999 99:99 NN\n>>>>>>>>>>> Nn: Nnnn Nnnnn\n >>>>>>>>>>> Nn: NNN Nnnnnn\; Nnnn Nnnnnnnn\; +NNNN\; +NN Nnnnnn\n>>>>>>>>> >> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>>>>>>\n>>>>>>>>>>> Nn\, Nnnn.\n>>>>>>>>>>>\n>>>>>>>>>>> Nnnnnnnnnnnn nnnnnn nnnnnn nn nnnn n n nnnnnn@nnnnnnnn.nn\, nnnnn nn n nnnnnnnnnnnn nnnn nnn nnnnn nnnn nnn.\n> >>>>>>>>>>\n>>>>>>>>>>> Nnnn nnn nnnn nnnnnn NNN nnnnnn nnnn nnnnnnnn nnnn nnnnn nnnn n nnnnnnnnn nnnnnn?\n>>>>>>>>>>>\n>>>>>>>>>>> --\n>>>>>>>>>>> N nn/Nnnnnnn\n>>>>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>>>>>>>> Nnnnnnnn Nnnn NN \n>>>>>>>>>>>\n>>>>>>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, Nnnn Nnnnn nnnn n:\n>>>>>>>>>>>\n>>>>>>>>>>>> Nn Nnnnn\,\n>>>>>>>>>>>>\n>>>>>>>>>>>> Nn NN N nnnnnn\, N nnn nnnnnnn nnnn nn nnnn nnnnnn nnnn nnnn\n>>>>>>>>>>>> nnnnn nn n nnnnnnnnn nnnnnn. Nnn nnnnnnnnnnnn nnnn nn\n>>>>>>>>>>>> nnnnnnnnnnn nn nn nnnnn nnnnnnnnnnnn\, nnnnnn nnn nn nnnn\n>>>>>>>>>>>> nnn nnnnnn nn nnn nnnnnnnnnn nn nnnn nnnnn.\n>>>>>>>>>>>>\n>>>>>>>>>>>> Nnn nnnnnnn nnn nnnnn nn NNN/NNN nnnnnn nn nnn nnnn nnnn nnnn nn nnnnn.\n>>>>>>>>>>>>\n>>> >>>>>>>>> Nnnnnnn\,\n>>>>>>>>>>>>\n>>>>>>>>>>>> Nnnn Nnnnn\n>>>>>>>>>>>>\n >>>>>>>>>>>> N: +99 (9)99 9999 9999 | N: +99 (9)99 9999 9999\n>>>>>>>>>>>> \n>>>>>>>>>>>> -----Nnnnnnnn Nnnnnnn-----\n>>>>>>>>>>>> Nnnn: Nnnnn N. Nnn nnnnnnnn [nnnnnn:nnn@nnnnnnnn.nn]\n>>>>>>>>>>>> Nnnn: Nnnnnnnn\, Nnnn 9\,= =20 9999 99:99 NN\n>>>>>>>>>>>> Nn: NNN Nnnnnn\n>>>>>>>>>>>> Nn: Nnnn Nnnnnnnn \; +NNNN\; +NN Nnnnnn\n>>>>>>>>>>>> Nnnnnnn: Nn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>>>>>>>\n>>>>>>>>>>>> Nn\, Nnnnn.\n>>>>>>>>>>>>\n>>>>>>>>>>> > Nn nnnnnnnnnnn nnnn nnnnnnnnn nnnn nnnn.nnnnnnnn.nn\, 99.99.999.99.\n>>> >>>>>>>>>\n>>>>>>>>>>>> --\n>>>>>>>>>>>> Nnn/Nnnnnnn\n>>>>>>>>>>>> Nnnnn N . Nnnnnnnnnnn\n>>>>>>>>>>>> Nnnnnnnn Nnnn NN\n>>>>>>>>>>>>\n>>>>>>>>>>>> N n Nnn\, Nnn 99 9999 nn 99:99\, NNN Nnnnnn nnnnn:\n>>>>>>>>>>>>\n>>>>>>>>>> >>> Nn Nnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> N nnnn nnnnnnnn nnn nnnnnnn n nnn nn nnnn nnnnnn nnn nn nnnn nnnnnnnnn nnnnn N nnnn nnnnnnnnnnn nn nnn:\ n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn nnnnn n nnnnnnn nnnnnnn nnn NNN/NNN nnnnn n nn nnnn nnnnnn? Nnn nn nnnn nnnnnn nnnnnnnnnnnnn nnnnnnnnn nn nnnn nn n nnnnnnnn nnnnnnn?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnnnn nnnn nn nnnnnnn nnn nn:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn nnnnn nnnnnn nnn nn nnnnnn NN 999.99. 999.99 nnnn nnn\n>>>>>>>>>>>>> nnnnnnnn nnn nnnn NNN nnnnnnn. Nnnnn nnn nn nnnn nnnnnn nnnn NN nnn nnnn nn nnnnnnnnnn nnnn nn nn nnn nnnnnnnnnn nnn n n nnn nnnnnnnn?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnn nnnn NNN nnnnnnn nn nnnn nn 9.9. Nnn99 nn nnn nnnnnnnnn\n>>>>>>>>>>>>> nnn nn nnnnnnnnn nn nnnn nn= =20 nn nnnnnnnn. Nnn9999 nn nnnnnnnnn nnn nnn nnnnnnnnnn\, nnnnnnn\, nn nnn nn nnnnn nn nnnn nnnnnn 9999=3DNNN.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn nn nnnnn= nn n nn nnnnnnnn nnnnnnnnnn nnn NNN nn Nnn nn nnn nn nnn nnnnnnn nn nnn nnnnn .\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnnn nnn9 nnn nnnnnnnnnn nnnn nn nnnn nn= =20 nnn nnn nnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnn nnnnnnn\,\n>>>>>>>>>>>>> \n>>>>>>>>>>>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>>>> >>>>>>\n>>>>>>>>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnn n Nnnnn Nnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>> >>>>>>>>>\n>>>>>>>>>>>>> Nnnnnn\, NN9N 9NN\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> + 999999999999 | Nnnn: nnnnnnnnn@nnn.nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> nnnnn nnnn@nnn.nnn | nnn.nnn.nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> -----Nnnnnnnn Nnn nnnn-----\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnn: Nnnnn N. Nnnnnnnnnnn [nnnnnn :nnn@nnnnnnnn.nn]\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnn: 99 Nnnn 9999 9:99 NN \n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn: Nnnnn Nnnnnnnn \n>>> >>>>>>>>>>\n>>>>>>>>>>>>> Nn: NNN Nnnnnn \; Nnnn Nnnnnn nn\n>>>>>>>>>>>>> \;\n>>>>>>>>>>>>> +NNNN \n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnnnnn: [NNN] Nn: Nnnnnnn nnnnnnn nn NNN\ n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn nnnnn.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnn n nnnnnnnnn nnnnn nn nnnn nnnn nnnnn nnnnnnnnnnnnnnn\, N nnnnn.\n>>>>>>>> >>>>> Nn nn nnnn nn nnnnnnn 99=3DNNNN\;9999=3DNNN\, nn nn nnn nnnnnnn nn n= Nnn nnnNnnNN nnn Nnnnnnnn nnnnn nn n NNN nnnnn? Nnn nnn nnnn NNN nnnnnnn nn n nnnn 9.9\, nnnnnnn?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn nnnnnnn nnn nnn nnnnn n nn nnn 99 nnn nnnnnnnnn\, nn nnnn nnnnnn nn nn.\n>>>>>>>>>>>>>\n>>>>>>>> >>>>> Nn nnn'n nnnnnnnnn nnnnnnn n NnnnNnNnnnn\, nnn nn nnnnnnnn nn n nnn= =20 nnnnn. Nnnn nn nnnnn nnnnnnn nn nnn nnnnnn nn nnn nnn nnnnnn?\n>>>>>>>>>> >>>\n>>>>>>>>>>>>> Nn nnn nn nnnnnnnnnn nn nnnnnnnn nn nnnnnnn nnnn nnnnn\ ,\n>>>>>>>>>>>>> nnn nnnnnn nnn nnnnnn nn nn nnnnn NNN nnn/nn NNN nnnnnn\, \n>>>>>>>>>>>>> nn N nnnnnnn nn nnn nnnnnnnnn nnnnnnnnn NNN nn nnnnnnn nnn nnnnnn nnnn nnn\, nnn nnnnnn nn nnnn nnnnnnnn nn nnnnnnnnn nnnnnn. Nn nn nnn n nnnnnnn nnnnnnn nnn NNN/NNN nnnnnn nn nnnn nnnnnn? Nnn nn nnnn nnnn nn nnnnnnnnnnnnn nnnnnnnnn nn nnnn nn nnnnnnnnn nnnnnnn?\n>>>>>>>>>>>>>\n> >>>>>>>>>>>> Nn nnnn nnn nnn Nnnnnnn(9) nnn nnn nnnnn nn nnnnnnn nnn nnnnn nnnnn nnnnnnn. Nnnn nnnn nnnnnnnn nn nnnn nn nnn nnn nnnnnn?\n>>>>>>>>>>> >>\n>>>>>>>>>>>>> --\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnn/Nnnnnnn\n>>>>>>>>>> >>>\n>>>>>>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nnnn nnnn Nnnn NN\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, Nnnnn N. Nnnnnnnnnnn nnnnn:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nn.\n>>>>>>>>> >>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nnnnn nnnnn nnn nnnnn\ , N nnn nnn nn nnn nnnnnn nnn nnnn\n>>>>>>>>>>>>>> nn nnnn nnnn\,\n>>>>>>> >>>>>>\n>>>>>>>>>>>>>> nnn nnnnn nnnn nn nnnnnnnnn nnnnnnnn nn nn nnnnn nn nnnnnn.\n>>>>>>>>>>>>>> N nn nnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> nnnnnnnnn nnn nnnnnnnnnnnnn nnn nnnn nn\, nnn nnnn nnn\n>>>>>>>>>>>>>> nnnn nn nnn= =20 nnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> nnn nnnnnnnnn.\n>>>>>>>>>>>>>\n>>>>>>> >>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> N nnnn nnn nnnnnnnnn nnnnnnnn\, nnn nnnnnn nnn NNN nnnnnnn\n>>>>>>>>>>>>>> nnn nnnn nnn\n>>>>>>>>>>>>>\n>>>>>> >>>>>>>> nn: nnnnn NN\, nnn nnn nnn nnnnnnnnn nnnnnnnnnnn nnn NNN\n>>>>>>> >>>>>>> nn nnnn nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nnnnnnnn?\n>>>>>>>>>>>> >\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> --\n>>>>>>>>>>>>>\n>>>>>> >>>>>>>> Nnn/Nnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nnnnn N. Nnnnnnnnnnn\n >>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nnnnnnnn Nnnn NN\n>>>>>>>>>>>>>\n>>>>>>>>>>> >>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> Nn Nnn\, Nnn 99 9999 nn 99:99\, Nnnnn N nnnnnnn nnnnn:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>> >>> Nn Nnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>> >>>> Nnnnnn nnn nn nnnn nn nnnnnnnn nnnnn nn nnnnnnn\, nnn N nnnn nn nnnnn nn nnnnnn. Nn nnn nnnnn nnnnnn nn nnnnnnn nnnn nnn nnnnn nnnnnn nnnn nnnn .\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnn nnn nnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnn nn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn Nnnnn Nnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>> >>>> [Nnnnnnnnnnn: Nnnnnnnnnnn:\n>>>>>>>>>>>>>>> nnn:nnnnn999.nnn@99NN9999 .99999N99]\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>>>>>>> >>\n>>>>>>>>>>>>>>> Nnnn Nnnnn Nnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> 99= =20 Nnnnnnnnnn Nnnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnnnn\, NN9N 9NN\n>>> >>>>>>>>>>\n>>>>>>>>>>>>>>> +999999999999 | Nnnn:\n>>>>>>>>>>>>>>> +nnnnnn nnn@nnn.nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnn nnnnn@nnn.nnn |\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>= =20 nnn.nnn.nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>> >>>>>\n>>>>>>>>>>>>>>> Nnnn: Nnnnn Nnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>> > Nnnn: 99 Nnn 9999 99:99 NN\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nn: 'nnn@nnnn nnnn.nn' \n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nn: +NNN Nnnnnn \; Nnnn Nnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> \; +NNNN \n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnn nnn: Nnnnnnn nnnnnnn nn NNN\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>> \n>>>>>>>>>>>>>>> Nn Nnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>> >\n>>>>>>>>>>>>>>> N nnnn nnnn nnnnn nnnn nnnnnnn nnnnnnnnnnn nn nnnnnnn n n nnnnnnn nnnnnnn nnnnnnn nnnnnnn nnnnnnnnnn nnn NNN.\n>>>>>>>>>>>>>\n>>>> >>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> N nnnnnnnnnn nnnn nnn nnn nnnn nnn nn nnnnnn n nnnnnnnnn\n>>>>>>>>>>>>>>> NNN NNN\, nnn\n>>>>>>>>>>>>>\n> >>>>>>>>>>>>>> nn nnnn nnnn nn nnnn nnn nnnnnnn nnn nnnn nnn nnnnn. N\n>>> >>>>>>>>>>>> nnnnnnnnnn nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnn nn nnnnnn n NNN nnnnnn nnnn. N nnnn nnnnnnnn nnn\n>>>>>>>>>>>>>>> nnnnnnn NNN\n>>>>> >>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnnnnnnnn\, nnnnn nnn nnn nnnn nnnnnn - Nnn= =20 NNN\n>>>>>>>>>>>>>>> nnnnnn nnnn nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnn= =20 nnnnnnnnn nn n NNN nnnnnnnn nnnnn\, nn nnnn nn nnn\n>>>>>>>>>>>>>>> NNN NN N nnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nn nnn nnn NNN nnnnnn nn nn nnnnnnn .\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> N nnn nn nnnnnnnnn nnnn n NNN nnnnnnn nnn nn nnn nnn nn nnnnn. Nn nnn nnnn nnnn nn nn nnnnnnn\, nn nnnnn n nnn NNN nnnnnnn nnn nnn\, nn nnn nnnnnn.\n>>>>>>>> >>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnNnnnNN=3DNNNN= \n >>>>>>>>>>>>>\n>>>>>>>>>>>>>>> NnnnnnNnnnNN=3DNNN\n>>>>>>>>>>>>>\n>>>>>>>>= >> >>>>> Nnnn=3D9999\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>= >> >>>>> N nnnn nnnnnnn nn nnnnnnn nnnn nnn.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\ n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnn nnnnnnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>> >>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnnn Nnnnnnnn | Nnnnnnnnnn Nnnnnnnn= =20 Nnnnn Nnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> [Nnnnnnnnnnn: Nnnnnnnnnnn:\n> >>>>>>>>>>>>>> nnn:nnnnn999.nnn@99NN9999.99999N99]\n>>>>>>>>>>>>>\n>>>>>>> >>>>>>>> NNN Nnnnnn Nnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnn Nnnnn Nnn nn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> 99 Nnnnnnnnnn Nnnnnn\,\n>>>>>>>>>>>>> \n>>>>>>>>>>>>>>> Nnnnnn\, NN9N 9NN\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> +99999 9999999 | Nnnn:\n>>>>>>>>>>>>>>> +nnnnnnnnn@nnn.nnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnnnn@nnn.nnn |\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnn.nnn.nnn\n >>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn\n>>>>>>>>>>>>>>> nnn nnnnnnnnnn \n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn\n>>>>>>>>>>>>>>> nnnnnnnnnnn nnnn nn\n>>>>>>>>>>>>>\n>>>>>>>>>>>> >>> nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn\n>>>>>>>>> >>>>>> nn nnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnnnnnnn nn nnn nn nnn nnnnnnn. Nnn nnnnnnnnnnnn nnn\,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnnnnn nnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn\n>>>>>>>>>>>>>>> nnnnnnnnnnn nn \n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn= =20 nnn nnnn\n>>>>>>>>>>>>>>> nnnnnnnn nnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nn nnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn\n>>>>>>>>>>>>>>> nnnnnnnnnn n nn nnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> n-nnnn\, nnn nnnnnnnnnnn nnnnn n nn nnnnnnn nnnn n-nnnn\,\n>>>>>>>>>>>>>>> nnn\n>>>>>>>>>>>>>\n>>>>>>>>>> >>>>> nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnnnn\n>>>>>>>>>>> >>>> nnnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnn nn nnnn n-nnnn\, nnn nnnn nn nnnn nnnnnnn nnnnnn nn\n>>>>>>>>>>>>>>> nnnnnnnnn nn\n>>>>>>>>>>>> >\n>>>>>>>>>>>>>>> n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn\n>>>> >>>>>>>>>>> nnnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> nnnnnnnnnnn nnn nnnn nnnnnnn nnnnnnnnn NNN'n nnnnnnnn nnn\n>>>>>>>>>>>>>>> nnnnnnnn\,\n>>>>>>>> >>>>>\n>>>>>>>>>>>>>>> nnnnnn nnnnn nn nnn nnnnnnnnn\n>>>>>>>>>>>>>\n>>>>> >>>>>>>>>> nnnn:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>> >>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n>>>>>>>>>>>>>\n>>>>>>> >>>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn nnn\n>>>>>>>> >>>>> nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn\n>>>>>>>>>>>>>= =20 nnnnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\,\n>>>>>>>>>>>>> nnn nnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn\n>>>>>>>>>>>>> nnn n n nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnn nnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nn n nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnn nnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnn nnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnn nnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnn nnnnnnn nnnnnnnnn NNN=E2=80=99n nnnnnnnn nnn nnnnnnnn\, nnnnnn nnnnn nn nn= n nnnn nnnnn nnnn:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnnn- nnnnnnnnnnn\n>>>>>>>>>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnn n nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnn nnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnn nn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnn nnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnn nnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnn n\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnn n nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnn n nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnn nnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnn nn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN=E2=80=99n nnnnnnnn = nnn nn nnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>>>>>>>>>>>\n>>>>>>>>>>>> n nnn://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n>>>>>>>>>>> Nnnn n-nnnn nnn nn n nnnnnnnnnnn nnn nnnnnnnn nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnn n. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnn nnnn nnnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn= =20 nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnn nnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnn nnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnn nnnnnn NNN=E2=80=99n nnnnnnnn nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn= nnnn: \n>>>>>>>>>>>\n>>>>>>>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n>> >>>>>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn nnn nnnnnnn nnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnnnnnnnnnn nnnn nn= =20 nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnn nnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nnnn nnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnnnn nn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnn nn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn nnn nnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nnnn nnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN=E2=80=99n nnnnnnnn nnn nnnnnnnn\, nn= nnnn n nnnn nn nnn nnnnnnnnn nnnn:\n>>>>>>>>>>\n>>>>>>>>>> nnnn://nnn.nnn.nnn/nnn nn/nnnnnn-nnnnnnnnnnn\n>>>>>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnn nn nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnn nn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\ , nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn n n nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn n n nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnn nnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn ( nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnn n nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nn nnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN=E2=80=99n nnn= nnnnn=20 nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>>>>>>>\n>>>>>>>> nnn n://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n>>>>>>> Nnnn n-nnnn nnn nnn nnnn nnnnnnn nnn nnnnnnnn nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnn nnnn nnn nnn nnnnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnn n nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn n nnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn n nnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\ , nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnn n\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN=E2=80=99n nnnnnnnn nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:= \n>>>> >>>\n>>>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n>>>>>>\n>>>>>> N nnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn nnn nnnnnnnnnn nn nnn nnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnn nn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nnnnnnn nn nnn n nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnn n nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnnnnnn nnnn n- nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nnnnnn nnnnnnn nn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn= =20 n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nn n nnnnnnnnnnn nnnnnnnnn NNN=E2=80=99n nnnnnnnn nnn nnnnnnnn\, nnnnnn nnnnn= nn nn n nnnnnnnnn nnnn:\n>>>>>>\n>>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnnn-nnnnnnnn nnn\n>>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn nnn nnnnn nnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnnnnnnnnnn nnnn n n nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnn nnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nn nnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn= =20 nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnnn\, nnnnnn nnnn nn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnn nnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn nnnnn). Nn nnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnnnnn nnnnnn nn n nnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nn nnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN=E2=80=99n nnnnnnnn nnn nnnnnnnn\, = nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>>>>\n>>>>> nnnn://nnn.nnn.nnn/nnnnn/nnnnn n-nnnnnnnnnnn\n>>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnnn nnn= =20 nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnnnnnnnn nn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn= =20 nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnn nnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnnn\, nn nnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnn nn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnnn nn n nnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnnnnn nn nnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnn nnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN=E2=80=99n nnnnnnnn nnn nn= nnnnnn \, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>>>\n>>>> nnnn://nnn.nnn.nnn/nnnn n/nnnnnn-nnnnnnnnnnn\n>>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn nnn n nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn nnn nnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnn nn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnn nnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnn nnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn nnnn n\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnn n nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnnnnn n nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn nnnn nnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnn nn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN=E2=80=99n nnnnnnnn = nnn nn nnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>>\n>>> nnnn://nnn.nnn.nnn/ nnnnn/nnnnnn-nnnnnnnnnnn\n>> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnnnnnnn= =20 nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nnnnnnn= =20 nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nn nnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, n nnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn n nnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnnn nn n nnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnn nnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnnn (nnn nnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn nnnn n nnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnn nnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN=E2=80=99n nnnnnn= nn nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>>\n>> nnnn://nnn.nnn.nnn /nnnnn/nnnnnn-nnnnnnnnnnn\n>>\n>>\n> Nnnn n-nnnn nnn nnn nnnnnnnnnnn nnn n nnnnnnn nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn= =20 nnnnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn \, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn nnn\, nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn nn nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnn nnn nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn nnnnnnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnn nnn (nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn n n nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. N nn nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN=E2=80=99= n nnnn nnnn nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n>\n> nnnn://nnn.n nn.nnn/nnnnn/nnnnnn-nnnnnnnnnnn\n\nNnnn n-nnnn nnn nnn nnnnnnnnnnn nnn nnn nnnnn nnnn nnn nnn nnnnnnnnnn nn nnnnnn nn nnnn nn nn nnnnnnnnn nnn nnn nn nnnnn nnnnnnnnnnn nnnn nn nnnnnnnnnnnn\, nnnnnnnnnn\, nnnnnn nnnnnnnnnnn\, nn nnnnnnn nn nnnnn nnnnnnnnnnnn nn nnn nn nnnnnnnnnn. Nnn nnnnnnnnnnnn n nn\, nnnnnnnnnnnnn nn nnnnnnn nn nnnn nnnnnnnnnnnn nn nnn nnnnnnnnnnn nn n n nn nnnnnnnnnn nnn nnn nn nnnnnnnn. Nn nnn nnnn nnnnnnnn nnnn nnnnnnnnnnn n nn nnnnn\, nnnnnn nnnnnn nnn nnnnnn nnnnnnnnnnn nn nnnnnn n-nnnn\, nnn n nnnnnnnnnn nnnnnn nn nnnnnnn nnnn n-nnnn\, nnn nnnnnnnnnnn\, nnn nnn nnnnn n (nnnnnnn nn nnnnn). Nnnnnn nnnnnnnnn nnnnnn nn nnnn n-nnnn\, nnnnnnn nn= =20 nnnn nnnnnnn nnnnnn nn nnnnnnnnn nn n nnnnnnn nn nnnnnnnnnn nnnnnnnnn. Nnn nnnnnnnnnn nnnnnnnnn nnnnnnnnnnn nnn nnnnnnnnnnn nnnnnnnnn NNN=E2=80=99n = nnnnnn nn nnn nnnnnnnn\, nnnnnn nnnnn nn nnn nnnnnnnnn nnnn:\n\nnnnn://nnn.nnn.nn n/nnnnn/nnnnnn-nnnnnnnnnnn\n --=-=-= Content-Type: text/plain Here is my analysis from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#27 again: --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Subject: bug#24358: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" Date: Sat, 03 Sep 2016 11:43:16 -0400 MIME-Version: 1.0 Content-Type: text/plain > (I'm also on GNU/Linux, Arch) I get the same max-specpdl-size error > with 25.1.50 [this refers to the master branch which is now 26.0.50 > (emacs-25 was 25.0.xx at the time)]. With emacs version 24.5 (and > below) I get (error "Stack overflow in regexp matcher") [as expected]. The problem is that re_max_failures is set to 40001 (instead of the original 40000) in main()[1], which is a problem because of the GROW_FAIL_STACK uses (re_max_failures * TYPICAL_FAILURE_SIZE) as a cap on the amount to allocate, but ((fail_stack).size * sizeof (fail_stack_elt_t)) to calculate current allocation. Since TYPICAL_FAILURE_SIZE = 20 and sizeof (fail_stack_elt_t) = 8, and it seems that (fail_stack).size grows in increments of 3, when (fail_stack).avail is 99999 and (fail_stack).size reaches 100002: (fail_stack).size * sizeof (fail_stack_elt_t) => 800016 re_max_failures * TYPICAL_FAILURE_SIZE => 800020 ENSURE_FAIL_STACK(3) then loops indefinitely reallocating a stack of size 800020 again and again until the record_xmalloc fails to grow_specdl() (thus the "max-specpdl-size" error). ---------- So we we might want to fix the re_max_failures setting in main, but it doesn't quite make sense to me that GROW_FAIL_STACK relies on re_max_failures being a multiple of (sizeof (fail_stack_elt_t)). At the definition of TYPICAL_FAILURE_SIZE we have /* Estimate the size of data pushed by a typical failure stack entry. An estimate is all we need, because all we use this for is to choose a limit for how big to make the failure stack. */ /* BEWARE, the value `20' is hard-coded in emacs.c:main(). */ #define TYPICAL_FAILURE_SIZE 20 Why do we use an "estimate" here? What's wrong with just using (re_max_failures * sizeof (fail_stack_elt_t)) as the limit? Or should the limit actually be (re_max_failures * TYPICAL_FAILURE_SIZE * sizeof (fail_stack_elt_t))? ----------- 827 long lim = rlim.rlim_cur; (gdb) p rlim $1 = { rlim_cur = 8388608, rlim_max = 18446744073709551615 } (gdb) next 833 int ratio = 20 * sizeof (char *); (gdb) 834 ratio += ratio / 3; (gdb) 837 int extra = 200000; (gdb) p ratio $2 = 213 [...] (gdb) display ((newlim - extra) / ratio) 1: ((newlim - extra) / ratio) = 40000 (gdb) next 856 newlim += pagesize - 1; 1: ((newlim - extra) / ratio) = 40000 (gdb) 857 if (0 <= rlim.rlim_max && rlim.rlim_max < newlim) 1: ((newlim - extra) / ratio) = 40019 (gdb) 859 newlim -= newlim % pagesize; 1: ((newlim - extra) / ratio) = 40019 (gdb) 861 if (pagesize <= newlim - lim) 1: ((newlim - extra) / ratio) = 40001 (gdb) undisplay 1 (gdb) next 863 rlim.rlim_cur = newlim; (gdb) 864 if (setrlimit (RLIMIT_STACK, &rlim) == 0) (gdb) 865 lim = newlim; (gdb) 870 re_max_failures = lim < extra ? 0 : min (lim - extra, SIZE_MAX) / ratio; (gdb) 875 stack_bottom = &stack_bottom_variable; (gdb) p re_max_failures $3 = 40001 ----------- [1]: This was the case since 9d356f62 2016-05-27 "Robustify stack-size calculation" --=-=-=-- From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Nov 2016 08:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@users.sourceforge.net Cc: 24751@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.14782477151413 (code B ref 24751); Fri, 04 Nov 2016 08:22:02 +0000 Received: (at 24751) by debbugs.gnu.org; 4 Nov 2016 08:21:55 +0000 Received: from localhost ([127.0.0.1]:42985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c2Zl4-0000Mj-Rq for submit@debbugs.gnu.org; Fri, 04 Nov 2016 04:21:55 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c2Zl4-0000MY-5Z for 24751@debbugs.gnu.org; Fri, 04 Nov 2016 04:21:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2Zkw-0000se-04 for 24751@debbugs.gnu.org; Fri, 04 Nov 2016 04:21:49 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2Zkv-0000sW-TJ; Fri, 04 Nov 2016 04:21:45 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2057 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c2Zkv-0004pm-0K; Fri, 04 Nov 2016 04:21:45 -0400 Date: Fri, 04 Nov 2016 10:22:08 +0200 Message-Id: <83h97nlknj.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87twc6tl0i.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) References: <87twc6tl0i.fsf@users.sourceforge.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.3 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.3 (-------) > From: npostavs@users.sourceforge.net > Date: Thu, 20 Oct 2016 23:54:05 -0400 > > So we we might want to fix the re_max_failures setting in main, but it > doesn't quite make sense to me that GROW_FAIL_STACK relies on > re_max_failures being a multiple of (sizeof (fail_stack_elt_t)). At the > definition of TYPICAL_FAILURE_SIZE we have > > /* Estimate the size of data pushed by a typical failure stack entry. > An estimate is all we need, because all we use this for > is to choose a limit for how big to make the failure stack. */ > /* BEWARE, the value `20' is hard-coded in emacs.c:main(). */ > #define TYPICAL_FAILURE_SIZE 20 > > Why do we use an "estimate" here? What's wrong with just using > (re_max_failures * sizeof (fail_stack_elt_t)) as the limit? Or should > the limit actually be (re_max_failures * TYPICAL_FAILURE_SIZE * sizeof > (fail_stack_elt_t))? I think it should be the latter, indeed. Can you propose a patch along those lines that would remove the infloop in ENSURE_FAIL_STACK? Thanks. From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2016 19:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24751@debbugs.gnu.org Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.147837443114321 (code B ref 24751); Sat, 05 Nov 2016 19:34:02 +0000 Received: (at 24751) by debbugs.gnu.org; 5 Nov 2016 19:33:51 +0000 Received: from localhost ([127.0.0.1]:46148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c36it-0003iu-7V for submit@debbugs.gnu.org; Sat, 05 Nov 2016 15:33:51 -0400 Received: from mail-it0-f41.google.com ([209.85.214.41]:37555) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c36ir-0003ih-Eh for 24751@debbugs.gnu.org; Sat, 05 Nov 2016 15:33:49 -0400 Received: by mail-it0-f41.google.com with SMTP id u205so45587134itc.0 for <24751@debbugs.gnu.org>; Sat, 05 Nov 2016 12:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=iEioWHfRLJylDpvygS+8hbCI4mYJCsXuL1HqKE/fOtI=; b=iMLA9/WwZv8+TxEGMycnA60I0FfM0wBedSp2+PCW8RiHaK+IGlrF8kgy56yX9AuTdz f0dgdRUsFad+6QEOVMpbynKfIbeIYDVJ6yB8nEVVeaz0WGVwLkp9RDY5rmVIE8JfhCsO Nc2DNTUUVn6eclVrEXIM+W/Ow81Fz/k6ISuxdswzHbCakSTqoTKpd8QjiszkN9hKBNHp 9/vvwx2wLY1slkpZZuNKsBrIPJS8Uj9z4TZntw9rBDlpR5y+BDdx4GtggjV4u9sM+Mrg D0sSXsyUi946q42eyNprXjRTbUBUUsOtSQNdueW77Gjh7qAfoAR1OyxSbI1XbqNyH9D6 578Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=iEioWHfRLJylDpvygS+8hbCI4mYJCsXuL1HqKE/fOtI=; b=GbVKnk2GoinU2x0iK47dvJ5QA11Fgk2vnThnFnTrxteT5VRUVFAitR3dWU8QcOPHXs FysXk/aWKbk+4LOyoG/gp9iAC+FlstPLQme7wkqG3/EwMNxm+MaxNZIrKRmFx1TeGb26 /2PdoeqKaXfuLXXunPPUEFUG4wUyxE0VaOrcJl4/0VgRZYJff/sIL4Fd6QlIXUaxrvxZ PM+dMD7X+VU3z9J8HZzDVKjTuxKvvACDVYWhUFEkqEtPTpanntJNSDXUjbdlcHLxr0ri MDKzzUOt1Tae4YTMD9r1CRFErrVhLhj0Ai7jPT5NAvC7pL5Y1QwS5UpzZCG8cpQCAmRw oAyA== X-Gm-Message-State: ABUngvfedH+GghUjHflce4BLY3NI/cRmy6LjlH/fJGJxz9/WxVrQIO3rpmxpGQ1KYJbNng== X-Received: by 10.36.73.134 with SMTP id e6mr1887952itd.109.1478374423549; Sat, 05 Nov 2016 12:33:43 -0700 (PDT) Received: from zony ([45.2.7.130]) by smtp.googlemail.com with ESMTPSA id u18sm1105651ita.2.2016.11.05.12.33.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 05 Nov 2016 12:33:42 -0700 (PDT) From: npostavs@users.sourceforge.net References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> Date: Sat, 05 Nov 2016 15:34:29 -0400 In-Reply-To: <83h97nlknj.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 04 Nov 2016 10:22:08 +0200") Message-ID: <87mvhdoh4q.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Eli Zaretskii writes: >> From: npostavs@users.sourceforge.net >> Date: Thu, 20 Oct 2016 23:54:05 -0400 >> >> So we we might want to fix the re_max_failures setting in main, but it >> doesn't quite make sense to me that GROW_FAIL_STACK relies on >> re_max_failures being a multiple of (sizeof (fail_stack_elt_t)). At the >> definition of TYPICAL_FAILURE_SIZE we have >> >> /* Estimate the size of data pushed by a typical failure stack entry. >> An estimate is all we need, because all we use this for >> is to choose a limit for how big to make the failure stack. */ >> /* BEWARE, the value `20' is hard-coded in emacs.c:main(). */ >> #define TYPICAL_FAILURE_SIZE 20 >> >> Why do we use an "estimate" here? What's wrong with just using >> (re_max_failures * sizeof (fail_stack_elt_t)) as the limit? Or should >> the limit actually be (re_max_failures * TYPICAL_FAILURE_SIZE * sizeof >> (fail_stack_elt_t))? > > I think it should be the latter, indeed. > > Can you propose a patch along those lines that would remove the > infloop in ENSURE_FAIL_STACK? > > Thanks. The below seems to work, but effectively increases the size of the failure stack (so the sample file size has to be increased 8-fold to get a regex stack overflow). Strangely, changing the value in the definition of re_max_failures doesn't seem to have any effect, it stays 40000 regardless. I am quite confused. diff --git i/src/regex.c w/src/regex.c index 1c6c9e5..163c5b4 100644 --- i/src/regex.c +++ w/src/regex.c @@ -1320,19 +1320,22 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) #define GROW_FAIL_STACK(fail_stack) \ (((fail_stack).size * sizeof (fail_stack_elt_t) \ - >= re_max_failures * TYPICAL_FAILURE_SIZE) \ + >= re_max_failures * sizeof (fail_stack_elt_t) \ + * TYPICAL_FAILURE_SIZE) \ ? 0 \ : ((fail_stack).stack \ = REGEX_REALLOCATE_STACK ((fail_stack).stack, \ (fail_stack).size * sizeof (fail_stack_elt_t), \ - min (re_max_failures * TYPICAL_FAILURE_SIZE, \ + min (re_max_failures * sizeof (fail_stack_elt_t) \ + * TYPICAL_FAILURE_SIZE, \ ((fail_stack).size * sizeof (fail_stack_elt_t) \ * FAIL_STACK_GROWTH_FACTOR))), \ \ (fail_stack).stack == NULL \ ? 0 \ : ((fail_stack).size \ - = (min (re_max_failures * TYPICAL_FAILURE_SIZE, \ + = (min (re_max_failures * sizeof (fail_stack_elt_t) \ + * TYPICAL_FAILURE_SIZE, \ ((fail_stack).size * sizeof (fail_stack_elt_t) \ * FAIL_STACK_GROWTH_FACTOR)) \ / sizeof (fail_stack_elt_t)), \ From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Nov 2016 15:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@users.sourceforge.net Cc: 24751@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.147844712227070 (code B ref 24751); Sun, 06 Nov 2016 15:46:02 +0000 Received: (at 24751) by debbugs.gnu.org; 6 Nov 2016 15:45:22 +0000 Received: from localhost ([127.0.0.1]:47069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c3PdK-00072Y-KL for submit@debbugs.gnu.org; Sun, 06 Nov 2016 10:45:22 -0500 Received: from eggs.gnu.org ([208.118.235.92]:35859) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c3PdI-00072H-MF for 24751@debbugs.gnu.org; Sun, 06 Nov 2016 10:45:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3PdA-0002x1-LW for 24751@debbugs.gnu.org; Sun, 06 Nov 2016 10:45:15 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3PdA-0002wr-Iu; Sun, 06 Nov 2016 10:45:12 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4672 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c3Pd9-0005oh-Qc; Sun, 06 Nov 2016 10:45:12 -0500 Date: Sun, 06 Nov 2016 17:45:40 +0200 Message-Id: <83zilcipcr.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87mvhdoh4q.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.0 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.0 (-------) > From: npostavs@users.sourceforge.net > Cc: 24751@debbugs.gnu.org > Date: Sat, 05 Nov 2016 15:34:29 -0400 > > >> #define TYPICAL_FAILURE_SIZE 20 > >> > >> Why do we use an "estimate" here? What's wrong with just using > >> (re_max_failures * sizeof (fail_stack_elt_t)) as the limit? Or should > >> the limit actually be (re_max_failures * TYPICAL_FAILURE_SIZE * sizeof > >> (fail_stack_elt_t))? > > > > I think it should be the latter, indeed. > > > > Can you propose a patch along those lines that would remove the > > infloop in ENSURE_FAIL_STACK? > > > > Thanks. > > The below seems to work Thanks. I think the patch can be simplified, where we now multiply by the size of fail_stack_elt_t and then divide by it: simply remove both the multiplication and the division. That will make the code easier to read, and will make the units of each variable clear, something that I think is at the heart of this issue. > but effectively increases the size of the failure stack (so the > sample file size has to be increased 8-fold to get a regex stack > overflow). Which IMO is exactly TRT, since re_max_failures was computed given the runtime stack size of 8MB, so having it bail out after merely 800KB doesn't sound right to me, don't you agree? > Strangely, changing the value in the definition of re_max_failures > doesn't seem to have any effect, it stays 40000 regardless. I am > quite confused. I don't think I follow. Can you tell what you tried to change, and where did you see the lack of any effect? From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Nov 2016 05:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24751@debbugs.gnu.org Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.147901554214671 (code B ref 24751); Sun, 13 Nov 2016 05:40:01 +0000 Received: (at 24751) by debbugs.gnu.org; 13 Nov 2016 05:39:02 +0000 Received: from localhost ([127.0.0.1]:55357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c5nVN-0003oL-50 for submit@debbugs.gnu.org; Sun, 13 Nov 2016 00:39:01 -0500 Received: from mail-it0-f43.google.com ([209.85.214.43]:38844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c5nVK-0003o2-NQ for 24751@debbugs.gnu.org; Sun, 13 Nov 2016 00:38:59 -0500 Received: by mail-it0-f43.google.com with SMTP id q124so51102383itd.1 for <24751@debbugs.gnu.org>; Sat, 12 Nov 2016 21:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=P9Y8wCVmtj1msQ1a3RokRsfAcUrmU6TjLpDazaOSYcQ=; b=s/Sofetg40SmF7S1J3fPKftM1JE8rLHBBbK9kpXoFJFAoKih2ck5LBu1VONKYmq9hY gMeZKjlScPOPWuPeApzdMk7n6BuaB0RY5EtOOZUaxjyXJk5Sip7XVjBVPDkDNV1hzkO0 rkh6coQYK3sKvCVf8yyMfb1aPryCBsGi3uW2QE4lfzxQ8iaDZ4iVMlf7yBo1pvPA39Wi wKIEclvbYRBZ/oRKhpWZKb8Rn61OZn1+j21ULsD0HJv+h1DtgdWjRj57fAk+ruFNfkQ6 KlynTAKqkJDMMGY/zk+bFcWmUSD8mJ8nTkFGrIEe+o7PoT7r8vIbzYNNTu342eQ3wv8U ds8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=P9Y8wCVmtj1msQ1a3RokRsfAcUrmU6TjLpDazaOSYcQ=; b=HiZHer6EnCFlTrbtZwavUpnbeBK5VZurilRYaUPbKgQJUU1WgCYM7m8/kFbP5Jfsed DZiItMCK/tabwMmYNglOK+Fo2dLyNWCgRcUoEYOMcXytZv5D9D3pkBfomys0Ljp+ZJ7d aHyT75nf6gN5/aB1hDcN1Lavk6qxEhf8iN9t9RZiLnGgX2f3lqKS7nlIbzkTx0X3sc07 +VuK0Voa+X0uGMyv25rt2buRkY0vWJ2b5tHKr4SiQbwbH6zlKlOfA7QWpKL4KfxLOC6A 7/xuVdlzR+HdeQDbl6oaGv8NOraFoXsEiH28xYUyezIS9L5vmGCQnMDjgpbHCot66CAf 46ag== X-Gm-Message-State: ABUngvcWBHA1cZKFSDN822y2w6W9pZdYaqiXOoHpS5QtlrbOnpBHNoi/6QOo3YlGlLUI5w== X-Received: by 10.107.175.147 with SMTP id p19mr22663887ioo.80.1479015532753; Sat, 12 Nov 2016 21:38:52 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id v197sm16966422ita.0.2016.11.12.21.38.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 12 Nov 2016 21:38:51 -0800 (PST) From: npostavs@users.sourceforge.net References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> Date: Sun, 13 Nov 2016 00:39:39 -0500 In-Reply-To: <83zilcipcr.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 06 Nov 2016 17:45:40 +0200") Message-ID: <87a8d4lyzo.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) --=-=-= Content-Type: text/plain Eli Zaretskii writes: > > I think the patch can be simplified, where we now multiply by the size > of fail_stack_elt_t and then divide by it: simply remove both the > multiplication and the division. That will make the code easier to > read, and will make the units of each variable clear, something that I > think is at the heart of this issue. Ah, right. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v2-0001-Fix-computation-of-regex-stack-limit.patch Content-Description: patch >From 7b24484346417c8fdf46fd7ee0be1758393f13fb Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sat, 5 Nov 2016 16:51:53 -0400 Subject: [PATCH v2] Fix computation of regex stack limit The regex stack limit was being computed as the number of stack entries, whereas it was being compared with the current size as measured in bytes. This could cause indefinite looping when nearing the stack limit if re_max_failures happened not to be a multiple of sizeof fail_stack_elt_t (Bug #24751). * src/regex.c (GROW_FAIL_STACK): Compute both current stack size and limit as numbers of stack entries. --- src/regex.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/src/regex.c b/src/regex.c index 1c6c9e5..d23ba01 100644 --- a/src/regex.c +++ b/src/regex.c @@ -1319,23 +1319,20 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) #define FAIL_STACK_GROWTH_FACTOR 4 #define GROW_FAIL_STACK(fail_stack) \ - (((fail_stack).size * sizeof (fail_stack_elt_t) \ - >= re_max_failures * TYPICAL_FAILURE_SIZE) \ + (((fail_stack).size >= re_max_failures * TYPICAL_FAILURE_SIZE) \ ? 0 \ : ((fail_stack).stack \ = REGEX_REALLOCATE_STACK ((fail_stack).stack, \ (fail_stack).size * sizeof (fail_stack_elt_t), \ - min (re_max_failures * TYPICAL_FAILURE_SIZE, \ - ((fail_stack).size * sizeof (fail_stack_elt_t) \ - * FAIL_STACK_GROWTH_FACTOR))), \ + min (re_max_failures * TYPICAL_FAILURE_SIZE, \ + ((fail_stack).size * FAIL_STACK_GROWTH_FACTOR)) \ + * sizeof (fail_stack_elt_t)), \ \ (fail_stack).stack == NULL \ ? 0 \ : ((fail_stack).size \ - = (min (re_max_failures * TYPICAL_FAILURE_SIZE, \ - ((fail_stack).size * sizeof (fail_stack_elt_t) \ - * FAIL_STACK_GROWTH_FACTOR)) \ - / sizeof (fail_stack_elt_t)), \ + = (min (re_max_failures * TYPICAL_FAILURE_SIZE, \ + ((fail_stack).size * FAIL_STACK_GROWTH_FACTOR))), \ 1))) -- 2.9.3 --=-=-= Content-Type: text/plain > >> but effectively increases the size of the failure stack (so the >> sample file size has to be increased 8-fold to get a regex stack >> overflow). > > Which IMO is exactly TRT, since re_max_failures was computed given the > runtime stack size of 8MB, so having it bail out after merely 800KB > doesn't sound right to me, don't you agree? Yes, I suppose we should also try to make use of the stack, rather than calling malloc, right? Something like this: diff --git i/src/regex.c w/src/regex.c index d23ba01..dcabde5 100644 --- i/src/regex.c +++ w/src/regex.c @@ -447,7 +447,11 @@ init_syntax_once (void) #else /* not REGEX_MALLOC */ # ifdef emacs -# define REGEX_USE_SAFE_ALLOCA USE_SAFE_ALLOCA +# define REGEX_USE_SAFE_ALLOCA \ + ptrdiff_t sa_avail = re_max_failures \ + * TYPICAL_FAILURE_SIZE * sizeof (fail_stack_elt_t); \ + ptrdiff_t sa_count = SPECPDL_INDEX (); bool sa_must_free = false + # define REGEX_SAFE_FREE() SAFE_FREE () # define REGEX_ALLOCATE SAFE_ALLOCA # else > >> Strangely, changing the value in the definition of re_max_failures >> doesn't seem to have any effect, it stays 40000 regardless. I am >> quite confused. > > I don't think I follow. Can you tell what you tried to change, and > where did you see the lack of any effect? Modifying the initial value of re_max_failures as in the below patch, has no effect on the size of the file at which stack regex overflow happens (I confirmed it gets compiled by adding a #warning on the previous line). Printing re_max_failures in gdb still shows 40000. diff --git i/src/regex.c w/src/regex.c index d23ba01..d9170c0 100644 --- i/src/regex.c +++ w/src/regex.c @@ -1249,7 +1249,7 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) whose default stack limit is 2mb. In order for a larger value to work reliably, you have to try to make it accord with the process stack limit. */ -size_t re_max_failures = 40000; +size_t re_max_failures = 20; # else size_t re_max_failures = 4000; # endif Actually I find Emacs still compiles if I removed that line completely, there's just a compile warning saying regex.o: In function `re_match_2_internal': /home/npostavs/src/emacs/emacs-master/lib-src/../src/regex.c:5529: warning: the 're_max_failures' variable is obsolete and will go away. I guess there's some kind of definition of it in libc? --=-=-=-- From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Nov 2016 16:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@users.sourceforge.net Cc: 24751@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.147905356830327 (code B ref 24751); Sun, 13 Nov 2016 16:13:01 +0000 Received: (at 24751) by debbugs.gnu.org; 13 Nov 2016 16:12:48 +0000 Received: from localhost ([127.0.0.1]:56009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c5xOi-0007t4-FS for submit@debbugs.gnu.org; Sun, 13 Nov 2016 11:12:48 -0500 Received: from eggs.gnu.org ([208.118.235.92]:47873) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c5xOg-0007so-Ec for 24751@debbugs.gnu.org; Sun, 13 Nov 2016 11:12:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c5xOX-0002bj-W7 for 24751@debbugs.gnu.org; Sun, 13 Nov 2016 11:12:41 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c5xOX-0002bf-T2; Sun, 13 Nov 2016 11:12:37 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4902 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c5xOX-00072y-8F; Sun, 13 Nov 2016 11:12:37 -0500 Date: Sun, 13 Nov 2016 18:12:47 +0200 Message-Id: <83a8d3cq9s.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87a8d4lyzo.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.8 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.8 (-------) > From: npostavs@users.sourceforge.net > Cc: 24751@debbugs.gnu.org > Date: Sun, 13 Nov 2016 00:39:39 -0500 > > > I think the patch can be simplified, where we now multiply by the size > > of fail_stack_elt_t and then divide by it: simply remove both the > > multiplication and the division. That will make the code easier to > > read, and will make the units of each variable clear, something that I > > think is at the heart of this issue. > > Ah, right. Thanks, LGTM. > >> but effectively increases the size of the failure stack (so the > >> sample file size has to be increased 8-fold to get a regex stack > >> overflow). > > > > Which IMO is exactly TRT, since re_max_failures was computed given the > > runtime stack size of 8MB, so having it bail out after merely 800KB > > doesn't sound right to me, don't you agree? > > Yes, I suppose we should also try to make use of the stack, rather than > calling malloc, right? Something like this: > > diff --git i/src/regex.c w/src/regex.c > index d23ba01..dcabde5 100644 > --- i/src/regex.c > +++ w/src/regex.c > @@ -447,7 +447,11 @@ init_syntax_once (void) > #else /* not REGEX_MALLOC */ > > # ifdef emacs > -# define REGEX_USE_SAFE_ALLOCA USE_SAFE_ALLOCA > +# define REGEX_USE_SAFE_ALLOCA \ > + ptrdiff_t sa_avail = re_max_failures \ > + * TYPICAL_FAILURE_SIZE * sizeof (fail_stack_elt_t); \ > + ptrdiff_t sa_count = SPECPDL_INDEX (); bool sa_must_free = false > + Yes. And please also add a comment there saying that this replaces USE_SAFE_ALLOCA. > -size_t re_max_failures = 40000; > +size_t re_max_failures = 20; > # else > size_t re_max_failures = 4000; > # endif > > > Actually I find Emacs still compiles if I removed that line completely, > there's just a compile warning saying > > regex.o: In function `re_match_2_internal': > /home/npostavs/src/emacs/emacs-master/lib-src/../src/regex.c:5529: warning: the 're_max_failures' variable is obsolete and will go away. > > I guess there's some kind of definition of it in libc? Most probably. You should be able to see that using "nm -A". If that's indeed so, I think we should rename that variable to something like emacs_re_max_failures, to avoid stomping on the libc variable.. From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Nov 2016 03:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24751@debbugs.gnu.org Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.147917925919137 (code B ref 24751); Tue, 15 Nov 2016 03:08:02 +0000 Received: (at 24751) by debbugs.gnu.org; 15 Nov 2016 03:07:39 +0000 Received: from localhost ([127.0.0.1]:57556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6U5y-0004ya-IB for submit@debbugs.gnu.org; Mon, 14 Nov 2016 22:07:38 -0500 Received: from mail-it0-f42.google.com ([209.85.214.42]:38015) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6U5w-0004yL-JI for 24751@debbugs.gnu.org; Mon, 14 Nov 2016 22:07:36 -0500 Received: by mail-it0-f42.google.com with SMTP id q124so164241176itd.1 for <24751@debbugs.gnu.org>; Mon, 14 Nov 2016 19:07:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=fYjoZ8LKEP98kKGGXHKu3Uk3eXXKxFNRCBxC1MxMjf8=; b=nekUdRdY/jHBgATMjz/7sKn1nTI93LJW5zEzezdy7GYrLV4rcMZkcALJ1YW9D81IR2 fLSzjjAnwGQh+bs4JTfsXekNxAdQCedjqUd1mkPwsrz86j5JRHk75OZMP1T1TE07zfA8 MXt+qkDtf1Ui4mYKSEWpXLH3/pFzN60ZEKjtUJUDHlK6T4RYzAy6ddsk3GBE/SdQ/Np4 srNV/KXcz1uOXtwmdwR/Oeml8lrgK0X4JwHe51EGmYpoxUZWVnu4B10/O4XHee7/85aA 4/X9sMT7lA28dQWTqz9F4VpGToSqhuJf0Ev1nNC/jetEbsaKoTmdMWlnOIB8mMdO2At0 IFrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=fYjoZ8LKEP98kKGGXHKu3Uk3eXXKxFNRCBxC1MxMjf8=; b=Q4NfoOP6q+c4eT+0v5P1oMPi3GhhBARDtXZcVHAedF5uEQoE5QwQEm1g75RRHiKyNu WUBJKuxSCJWjrliclJgApaYhKKpf1wWG3lZZmEAvYR21/WM98WJyEdfXYxlhhvp66L3k ryjnhL4rJZZowAt9J99UCq2MxaDGz4sDS7cG4TrjkFfn4jOIdprmTYxQPx6e8BG4bJKE EM7OkTAmWvOYrWNo46W1FLXcNvFY99O//iERMwlpNSG+8pMxVit9E6wNUREl0KaHzt3k IUXP3mNuvg2WTAoQ2PX4sDuJLOSIgDBBSr8tZZT+QzEuBFEcp8Iev6NtCZzsjbNGJCyX uonQ== X-Gm-Message-State: ABUngvdMmsZ3DG/NLRaSrn8KmznDjPR+1v1rALobHxpDIM+T2Tbc6R5EiP9VL21aZuVWVQ== X-Received: by 10.36.83.213 with SMTP id n204mr1217362itb.100.1479179250972; Mon, 14 Nov 2016 19:07:30 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id h142sm817710itb.1.2016.11.14.19.07.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 14 Nov 2016 19:07:30 -0800 (PST) From: npostavs@users.sourceforge.net References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> Date: Mon, 14 Nov 2016 22:08:18 -0500 In-Reply-To: <83a8d3cq9s.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 13 Nov 2016 18:12:47 +0200") Message-ID: <87wpg5l9st.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Eli Zaretskii writes: >> >> Yes, I suppose we should also try to make use of the stack, rather than >> calling malloc, right? Something like this: >> >> diff --git i/src/regex.c w/src/regex.c >> index d23ba01..dcabde5 100644 >> --- i/src/regex.c >> +++ w/src/regex.c >> @@ -447,7 +447,11 @@ init_syntax_once (void) >> #else /* not REGEX_MALLOC */ >> >> # ifdef emacs >> -# define REGEX_USE_SAFE_ALLOCA USE_SAFE_ALLOCA >> +# define REGEX_USE_SAFE_ALLOCA \ >> + ptrdiff_t sa_avail = re_max_failures \ >> + * TYPICAL_FAILURE_SIZE * sizeof (fail_stack_elt_t); \ >> + ptrdiff_t sa_count = SPECPDL_INDEX (); bool sa_must_free = false >> + > > Yes. And please also add a comment there saying that this replaces > USE_SAFE_ALLOCA. Actually, we should avoid increasing this limit if the stack wasn't increased, right? Here's what I came up with, I think it doesn't cover Cygwin/Windows though. diff --git c/src/emacs.c i/src/emacs.c index b74df21..d4655c8 100644 --- c/src/emacs.c +++ i/src/emacs.c @@ -831,8 +831,8 @@ main (int argc, char **argv) re_max_failures, then add 33% to cover the size of the smaller stacks that regex.c successively allocates and discards on its way to the maximum. */ - int ratio = 20 * sizeof (char *); - ratio += ratio / 3; + int min_ratio = 20 * sizeof (char *); + int ratio = min_ratio + min_ratio / 3; /* Extra space to cover what we're likely to use for other reasons. */ int extra = 200000; @@ -869,6 +869,7 @@ main (int argc, char **argv) /* Don't let regex.c overflow the stack. */ re_max_failures = lim < extra ? 0 : min (lim - extra, SIZE_MAX) / ratio; + emacs_re_safe_alloca = re_max_failures * min_ratio; } #endif /* HAVE_SETRLIMIT and RLIMIT_STACK and not CYGWIN */ diff --git c/src/regex.c i/src/regex.c index d23ba01..56cffa1 100644 --- c/src/regex.c +++ i/src/regex.c @@ -447,7 +447,13 @@ init_syntax_once (void) #else /* not REGEX_MALLOC */ # ifdef emacs -# define REGEX_USE_SAFE_ALLOCA USE_SAFE_ALLOCA +/* This may be adjusted in main(), if the stack is successfully grown. */ +ptrdiff_t emacs_re_safe_alloca = MAX_ALLOCA; +/* Like USE_SAFE_ALLOCA, but use emacs_re_safe_alloca. */ +# define REGEX_USE_SAFE_ALLOCA \ + ptrdiff_t sa_avail = emacs_re_safe_alloca; \ + ptrdiff_t sa_count = SPECPDL_INDEX (); bool sa_must_free = false + # define REGEX_SAFE_FREE() SAFE_FREE () # define REGEX_ALLOCATE SAFE_ALLOCA # else diff --git c/src/regex.h i/src/regex.h index 4922440..45cbe0a 100644 --- c/src/regex.h +++ i/src/regex.h @@ -187,6 +187,11 @@ /* Roughly the maximum number of failure points on the stack. */ extern size_t re_max_failures; +#ifdef emacs +/* Amount of memory that we can safely stack allocate. */ +extern ptrdiff_t emacs_re_safe_alloca; +#endif + /* Define combinations of the above bits for the standard possibilities. (The [[[ comments delimit what gets put into the Texinfo file, so >> >> >> Actually I find Emacs still compiles if I removed that line completely, >> there's just a compile warning saying >> >> regex.o: In function `re_match_2_internal': >> /home/npostavs/src/emacs/emacs-master/lib-src/../src/regex.c:5529: warning: the 're_max_failures' variable is obsolete and will go away. >> >> I guess there's some kind of definition of it in libc? > > Most probably. You should be able to see that using "nm -A". If > that's indeed so, I think we should rename that variable to something > like emacs_re_max_failures, to avoid stomping on the libc variable.. Ah, right: $ nm -A /usr/lib/libc.so.6 | grep re_max_failures /usr/lib/libc.so.6:0000000000000000 n __evoke_link_warning_re_max_failures /usr/lib/libc.so.6:00000000003981d8 D re_max_failures From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Nov 2016 16:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@users.sourceforge.net Cc: 24751@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.147922634110154 (code B ref 24751); Tue, 15 Nov 2016 16:13:02 +0000 Received: (at 24751) by debbugs.gnu.org; 15 Nov 2016 16:12:21 +0000 Received: from localhost ([127.0.0.1]:58376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6gLN-0002di-3I for submit@debbugs.gnu.org; Tue, 15 Nov 2016 11:12:21 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6gLL-0002dT-B1 for 24751@debbugs.gnu.org; Tue, 15 Nov 2016 11:12:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6gLF-0002tY-8x for 24751@debbugs.gnu.org; Tue, 15 Nov 2016 11:12:14 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6gLF-0002tR-5S; Tue, 15 Nov 2016 11:12:13 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3166 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c6gLE-0000QF-PA; Tue, 15 Nov 2016 11:12:13 -0500 Date: Tue, 15 Nov 2016 18:12:09 +0200 Message-Id: <83d1hwhgdi.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87wpg5l9st.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.8 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.8 (-------) > From: npostavs@users.sourceforge.net > Cc: 24751@debbugs.gnu.org > Date: Mon, 14 Nov 2016 22:08:18 -0500 > > Actually, we should avoid increasing this limit if the stack wasn't > increased, right? Here's what I came up with, I think it doesn't cover > Cygwin/Windows though. > > diff --git c/src/emacs.c i/src/emacs.c > index b74df21..d4655c8 100644 > --- c/src/emacs.c > +++ i/src/emacs.c > @@ -831,8 +831,8 @@ main (int argc, char **argv) > re_max_failures, then add 33% to cover the size of the > smaller stacks that regex.c successively allocates and > discards on its way to the maximum. */ > - int ratio = 20 * sizeof (char *); > - ratio += ratio / 3; > + int min_ratio = 20 * sizeof (char *); > + int ratio = min_ratio + min_ratio / 3; > > /* Extra space to cover what we're likely to use for other reasons. */ > int extra = 200000; > @@ -869,6 +869,7 @@ main (int argc, char **argv) > > /* Don't let regex.c overflow the stack. */ > re_max_failures = lim < extra ? 0 : min (lim - extra, SIZE_MAX) / ratio; > + emacs_re_safe_alloca = re_max_failures * min_ratio; > } > #endif /* HAVE_SETRLIMIT and RLIMIT_STACK and not CYGWIN */ Right, but I have 2 comments: . we shouldn't set re_max_failures to zero if the amount of stack is less than 'extra', since in that case we will allocate the failure stack off the heap; . emacs_re_safe_alloca should have its minimum value MAX_ALLOCA, not zero, because SAFE_ALLOCA can still be used in regex.c, even though the failure stack will be malloc'ed. Thanks. From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Nov 2016 01:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24751@debbugs.gnu.org Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.14792583471984 (code B ref 24751); Wed, 16 Nov 2016 01:06:01 +0000 Received: (at 24751) by debbugs.gnu.org; 16 Nov 2016 01:05:47 +0000 Received: from localhost ([127.0.0.1]:58662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6ofb-0000Vw-Iv for submit@debbugs.gnu.org; Tue, 15 Nov 2016 20:05:47 -0500 Received: from mail-it0-f42.google.com ([209.85.214.42]:36240) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6ofa-0000Vk-NX for 24751@debbugs.gnu.org; Tue, 15 Nov 2016 20:05:47 -0500 Received: by mail-it0-f42.google.com with SMTP id l8so37789193iti.1 for <24751@debbugs.gnu.org>; Tue, 15 Nov 2016 17:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=EqnFxklJJ7PXXoNLnr8rcHGm+vGeoQ2NMwev66AY+eU=; b=BaQlYjHKu216MM7teDc4G0FkLuhU5vixpQjQ0a29922YdoU5RoIBqXRHmkkz8V1uwM CQC/yhO01aLCp6hg0tWUtc001J/6KE4FM8YGEQOn7aOJJmucBV1Fs9rDTEJih5hfw/VT kPwsa+jDjmOpVroigZUE45L47hRfwMyWAsCheOcT+EYXaCsaxlighDPyC7+iS8He7poB QbiZchKHqPZoZ/P4jmfVmh+I6moODPLIrrEl6u2ZxYr9qaDyqAKB9ocdOgr0Ngg/AClt sCyM19oCkYQr3pgUfkIrnZ32tEjrN6qNSDIz4olE93WKHbb3pvUOP6FEWh08mtbpPYUW aWug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=EqnFxklJJ7PXXoNLnr8rcHGm+vGeoQ2NMwev66AY+eU=; b=LCc59jXFmcHdldLh6mPrkHpnn8J/FbFpsstdicHPBp6fiYhpQnFr53zWuZYpNWmouy Fx0fn6pkgH2pR5Ns5bEOQl5qhW9bour75aKoeSqzE9CPJoozMHYkFNtYq9nZBZSn9+5P PonjVAUGDyhjZI3Fkql62QOhtprdBmKdmiLgUaCyrCT1mIBM/kCXzKYe9M6XMWM5UgPP eSrMM2EVLPlWShW93X5+RXBf/WM73T0qdKCJAjmlRZqndHFVQiQbi2Pd7Zw4+F09zhyN nsM1yik0l7yiR51cmv+7XTsXEbEZMsQATl4FWtOMJTDsjzxy6p8ySoAcTzRZMJYByv8L GGCQ== X-Gm-Message-State: ABUngve4cwNwWik/qaJMcJoT0Sibo6q+6HXe+++VO6InnLkVqC8cSWg6eZYv35jrG2pTjg== X-Received: by 10.107.84.2 with SMTP id i2mr626084iob.225.1479258341120; Tue, 15 Nov 2016 17:05:41 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id n127sm2438791ita.22.2016.11.15.17.05.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 15 Nov 2016 17:05:40 -0800 (PST) From: npostavs@users.sourceforge.net References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> Date: Tue, 15 Nov 2016 20:06:29 -0500 In-Reply-To: <83d1hwhgdi.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 15 Nov 2016 18:12:09 +0200") Message-ID: <87r36ckzca.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) >> @@ -869,6 +869,7 @@ main (int argc, char **argv) >> >> /* Don't let regex.c overflow the stack. */ >> re_max_failures = lim < extra ? 0 : min (lim - extra, SIZE_MAX) / ratio; >> + emacs_re_safe_alloca = re_max_failures * min_ratio; >> } >> #endif /* HAVE_SETRLIMIT and RLIMIT_STACK and not CYGWIN */ > > . we shouldn't set re_max_failures to zero if the amount of stack is > less than 'extra', since in that case we will allocate the failure > stack off the heap; Then what should we set it to? Maybe we shouldn't modify it at all, since the stack isn't actually a limiting factor? From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Nov 2016 16:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@users.sourceforge.net Cc: 24751@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.14793135467687 (code B ref 24751); Wed, 16 Nov 2016 16:26:02 +0000 Received: (at 24751) by debbugs.gnu.org; 16 Nov 2016 16:25:46 +0000 Received: from localhost ([127.0.0.1]:59770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c731u-0001zv-2I for submit@debbugs.gnu.org; Wed, 16 Nov 2016 11:25:46 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c731s-0001zj-4X for 24751@debbugs.gnu.org; Wed, 16 Nov 2016 11:25:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c731j-0005DJ-Oz for 24751@debbugs.gnu.org; Wed, 16 Nov 2016 11:25:39 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c731j-0005DC-Lh; Wed, 16 Nov 2016 11:25:35 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4301 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c731h-0007PX-Ag; Wed, 16 Nov 2016 11:25:35 -0500 Date: Wed, 16 Nov 2016 18:25:22 +0200 Message-Id: <83polvfl3h.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87r36ckzca.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.9 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.9 (-------) > From: npostavs@users.sourceforge.net > Cc: 24751@debbugs.gnu.org > Date: Tue, 15 Nov 2016 20:06:29 -0500 > > >> @@ -869,6 +869,7 @@ main (int argc, char **argv) > >> > >> /* Don't let regex.c overflow the stack. */ > >> re_max_failures = lim < extra ? 0 : min (lim - extra, SIZE_MAX) / ratio; > >> + emacs_re_safe_alloca = re_max_failures * min_ratio; > >> } > >> #endif /* HAVE_SETRLIMIT and RLIMIT_STACK and not CYGWIN */ > > > > . we shouldn't set re_max_failures to zero if the amount of stack is > > less than 'extra', since in that case we will allocate the failure > > stack off the heap; > > Then what should we set it to? Maybe we shouldn't modify it at all, > since the stack isn't actually a limiting factor? Yes, I think this is the best solution. Thanks. From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Nov 2016 23:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24751@debbugs.gnu.org Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.147933868116030 (code B ref 24751); Wed, 16 Nov 2016 23:25:01 +0000 Received: (at 24751) by debbugs.gnu.org; 16 Nov 2016 23:24:41 +0000 Received: from localhost ([127.0.0.1]:59947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c79ZI-0004AU-S2 for submit@debbugs.gnu.org; Wed, 16 Nov 2016 18:24:41 -0500 Received: from mail-it0-f42.google.com ([209.85.214.42]:38203) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c79ZG-0004AG-LO for 24751@debbugs.gnu.org; Wed, 16 Nov 2016 18:24:39 -0500 Received: by mail-it0-f42.google.com with SMTP id j191so2152320ita.1 for <24751@debbugs.gnu.org>; Wed, 16 Nov 2016 15:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=3IAAtItJLf5ekii13xP4oHVCljaxxSjX2IF223J6znw=; b=Jr3GvKB+GXmsFDeWoMMrZsZRiP9c5V/9HhGWfrTnWRLdPHjL68BJvXJ4Me7OYcVk/u XCUNEPMkDOvgYQanawfEgCjbkxaM/Y4fhtT8dRALLxNWTpOsaFKwGBZPxcLqRy/HbPcQ NtWO2+0mTKLqb4E4KeyoQyGnuBU7Y82Nf2bsqTXB8xHx4CRD0A8cWpbrLjrkRwgpID3V k8+83c331YEz5WtVOGFDSg8tcpHe38S0IrhiP/bLKfNBR+i6lt3WhH2Kv0nHyxhlQFAE qXhcHFXb82J3Heze1g6a0hG3DZLyOOqX7RnXqA7PsAH/hn4Zin9e3/G724Cnc36SXu1i I/Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=3IAAtItJLf5ekii13xP4oHVCljaxxSjX2IF223J6znw=; b=BzI2NPvpJpeX2mfHPOOmy5cRnBz01Fp5n8aIddnPmDGknvwNCzuvtZkOotD/MgarKY 2bs5beNmKEJXKmOV4NB/G9Zi8fCt8PDCIkGQiynhVxZDKBGsufg3dyczCZzNMKcU6CcJ AcwRR10jYGRdcfWQ0ivN2tTWqYQgxkVBFKZTO2Z5sVnuvOSb+kUlH7j1qozYDvjGR4uH e0l6cRLJIz4T7L2jv9IvHcNcMQDsPt8wGHAnpV2+mnMoUJouvkmI+w8W6Kt1kLdMb3eC 2TpYY1F6d5E5rFlcNxH9r38c+SUDD4S7F8tKaJpMPuQKvVGA+gMpOMoM+JvBPwg1nisi 81aQ== X-Gm-Message-State: ABUngverPGfyDGsUJ8IyoDNjaA+sC5hzpd+mTDPtq1pPAcNdb+vNG5u1TqtGercpb/6NUA== X-Received: by 10.36.76.22 with SMTP id a22mr615913itb.44.1479338672825; Wed, 16 Nov 2016 15:24:32 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id o144sm259322iod.40.2016.11.16.15.24.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 16 Nov 2016 15:24:31 -0800 (PST) From: npostavs@users.sourceforge.net References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> Date: Wed, 16 Nov 2016 18:25:22 -0500 In-Reply-To: <83polvfl3h.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 16 Nov 2016 18:25:22 +0200") Message-ID: <87oa1fknx9.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Eli Zaretskii writes: >> From: npostavs@users.sourceforge.net >> Cc: 24751@debbugs.gnu.org >> Date: Tue, 15 Nov 2016 20:06:29 -0500 >> >> >> @@ -869,6 +869,7 @@ main (int argc, char **argv) >> >> >> >> /* Don't let regex.c overflow the stack. */ >> >> re_max_failures = lim < extra ? 0 : min (lim - extra, SIZE_MAX) / ratio; >> >> + emacs_re_safe_alloca = re_max_failures * min_ratio; >> >> } >> >> #endif /* HAVE_SETRLIMIT and RLIMIT_STACK and not CYGWIN */ >> > >> > . we shouldn't set re_max_failures to zero if the amount of stack is >> > less than 'extra', since in that case we will allocate the failure >> > stack off the heap; >> >> Then what should we set it to? Maybe we shouldn't modify it at all, >> since the stack isn't actually a limiting factor? > > Yes, I think this is the best solution. > One more question, is this comment (around line 1198) now obsolete? (if not, it sounds like we might still have some serious problems) /* Define MATCH_MAY_ALLOCATE unless we need to make sure that the searching and matching functions should not call alloca. On some systems, alloca is implemented in terms of malloc, and if we're using the relocating allocator routines, then malloc could cause a relocation, which might (if the strings being searched are in the ralloc heap) shift the data out from underneath the regexp routines. Here's another reason to avoid allocation: Emacs processes input from X in a signal handler; processing X input may call malloc; if input arrives while a matching routine is calling malloc, then we're scrod. But Emacs can't just block input while calling matching routines; then we don't notice interrupts when they come in. So, Emacs blocks input around all regexp calls except the matching calls, which it leaves unprotected, in the faith that they will not malloc. */ Also this one (around line 430) /* Should we use malloc or alloca? If REGEX_MALLOC is not defined, we use `alloca' instead of `malloc'. This is because using malloc in re_search* or re_match* could cause memory leaks when C-g is used in Emacs; also, malloc is slower and causes storage fragmentation. On the other hand, malloc is more portable, and easier to debug. Because we sometimes use alloca, some routines have to be macros, not functions -- `alloca'-allocated space disappears at the end of the function it is called in. */ From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Nov 2016 16:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@users.sourceforge.net Cc: 24751@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.147939969323259 (code B ref 24751); Thu, 17 Nov 2016 16:22:02 +0000 Received: (at 24751) by debbugs.gnu.org; 17 Nov 2016 16:21:33 +0000 Received: from localhost ([127.0.0.1]:60858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7PRN-000635-78 for submit@debbugs.gnu.org; Thu, 17 Nov 2016 11:21:33 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45221) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7PRL-00062r-CG for 24751@debbugs.gnu.org; Thu, 17 Nov 2016 11:21:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7PRD-00052U-3e for 24751@debbugs.gnu.org; Thu, 17 Nov 2016 11:21:26 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45356) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7PRD-00052N-0E; Thu, 17 Nov 2016 11:21:23 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1514 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c7PRC-0000yJ-AQ; Thu, 17 Nov 2016 11:21:22 -0500 Date: Thu, 17 Nov 2016 18:21:24 +0200 Message-Id: <83y40idqm3.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87oa1fknx9.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> <87oa1fknx9.fsf@users.sourceforge.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.9 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.9 (-------) > From: npostavs@users.sourceforge.net > Cc: 24751@debbugs.gnu.org > Date: Wed, 16 Nov 2016 18:25:22 -0500 > > One more question, is this comment (around line 1198) now obsolete? (if > not, it sounds like we might still have some serious problems) > > /* Define MATCH_MAY_ALLOCATE unless we need to make sure that the > searching and matching functions should not call alloca. On some > systems, alloca is implemented in terms of malloc, and if we're > using the relocating allocator routines, then malloc could cause a > relocation, which might (if the strings being searched are in the > ralloc heap) shift the data out from underneath the regexp > routines. > > Here's another reason to avoid allocation: Emacs > processes input from X in a signal handler; processing X input may > call malloc; if input arrives while a matching routine is calling > malloc, then we're scrod. But Emacs can't just block input while > calling matching routines; then we don't notice interrupts when > they come in. So, Emacs blocks input around all regexp calls > except the matching calls, which it leaves unprotected, in the > faith that they will not malloc. */ The second part is obsolete: we no longer do anything significant from a signal handler, we just set a flag. The first part is not obsolete, but its reasoning is backwards: SAFE_ALLOCA indeed can call malloc, but it could only cause relocation if REGEX_MALLOC is defined (and ralloc.c is compiled in). And when you define REGEX_MALLOC, MATCH_MAY_ALLOCATE is undefined. So the text there should be revised. > Also this one (around line 430) > > /* Should we use malloc or alloca? If REGEX_MALLOC is not defined, we > use `alloca' instead of `malloc'. This is because using malloc in > re_search* or re_match* could cause memory leaks when C-g is used in > Emacs; also, malloc is slower and causes storage fragmentation. On > the other hand, malloc is more portable, and easier to debug. > > Because we sometimes use alloca, some routines have to be macros, > not functions -- `alloca'-allocated space disappears at the end of the > function it is called in. */ This is correct AFAIU, but perhaps it's worth adding that even if SAFE_ALLOCA decides to call malloc, it takes care to set up unwind-protect scheme that will free the allocated memory upon C-g (or any other throw-type op), and avoid leaking memory. Thanks. From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Nov 2016 10:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@users.sourceforge.net Cc: 24751@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.147954973812237 (code B ref 24751); Sat, 19 Nov 2016 10:03:02 +0000 Received: (at 24751) by debbugs.gnu.org; 19 Nov 2016 10:02:18 +0000 Received: from localhost ([127.0.0.1]:34448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c82TS-0003BI-15 for submit@debbugs.gnu.org; Sat, 19 Nov 2016 05:02:18 -0500 Received: from eggs.gnu.org ([208.118.235.92]:36070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c82TQ-0003B5-QT for 24751@debbugs.gnu.org; Sat, 19 Nov 2016 05:02:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c82TI-00076t-Ip for 24751@debbugs.gnu.org; Sat, 19 Nov 2016 05:02:11 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c82TI-00076o-GP; Sat, 19 Nov 2016 05:02:08 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3637 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c82TH-0005Nq-DW; Sat, 19 Nov 2016 05:02:07 -0500 Date: Sat, 19 Nov 2016 12:02:14 +0200 Message-Id: <83lgwfbxeh.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <83y40idqm3.fsf@gnu.org> (message from Eli Zaretskii on Thu, 17 Nov 2016 18:21:24 +0200) References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> <87oa1fknx9.fsf@users.sourceforge.net> <83y40idqm3.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.9 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.9 (-------) One other comment: the value of 'extra' in emacs.c looks too small to me. If we want to safely allocate the failure stack off the run-time C stack, we should make 'extra' large enough to cover a typical GC, which can take as many as 30K stack frames. So I'd enlarge 'extra' to be something like 1500000. From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Jan 2017 18:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24751@debbugs.gnu.org Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.148329555921520 (code B ref 24751); Sun, 01 Jan 2017 18:33:01 +0000 Received: (at 24751) by debbugs.gnu.org; 1 Jan 2017 18:32:39 +0000 Received: from localhost ([127.0.0.1]:38780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNkvv-0005b0-LM for submit@debbugs.gnu.org; Sun, 01 Jan 2017 13:32:39 -0500 Received: from mail-io0-f171.google.com ([209.85.223.171]:36664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNkvu-0005an-Fz for 24751@debbugs.gnu.org; Sun, 01 Jan 2017 13:32:38 -0500 Received: by mail-io0-f171.google.com with SMTP id h133so164835187ioe.3 for <24751@debbugs.gnu.org>; Sun, 01 Jan 2017 10:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=fFbmkDMX01G5mCAo1m1WRnuGlVAcg5mljTnvKwhIC3o=; b=amJB/8R9tcYQYubHX0iAUQWYySC7DT4y276wPi5N1EzZzni3BOwL8gKiK5/YEo8DCU HnZBGOWlgNvEu/f3xgfcolcW3iQ9y6YxSS2Vot2+BcSyIHsrVvEcWXBPrS5HRo4rG9rg W/DpqODAswrtM1IuDmV0qlcHDqTkujs24OGp/RsgrsbDYD+a8rRO18FEuz7hjPtIfcb3 agvAK7mFsWfAgA8XzSRuK5WpkCbHONnoVaYhJsjKGJlB/qBq9Rv2A0WkS2wjBxe6C7mh H8NXP5espYKyL7qSEQ5BYr+LDQRv6cTdjBnHchpHRAPiJbqHTAWzw1B+MzlInQ0usmH5 dVew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=fFbmkDMX01G5mCAo1m1WRnuGlVAcg5mljTnvKwhIC3o=; b=jG4swIo1+TVMUNQ8b4wSKsua92nd6W/FlTdgifss/GkHqFOx5xJTKH9M7xrWN6sMmp 0p6AWELeeGHwKsdCSJTGL0t+O28czd6vDXAIb7jen0OkZqVMR3xcXUG6JHNbziQkbPbf 2dFj2DSHcwyKwfp97AvEhiiBHRrK9sh8n56H82I6qi255Hxs0xSxfXBxwsZgF4tPg29n 6SEWgH6G3jHiVsYRMltl5GJnh1UPBmjqqb+lQDPmhJayNxsomERnadpZEr7NUdFLWrv8 kzPmtRM02R618Ih6S+NSghU7A6/U4faj7qsvcckVDVW7Sv2XzhlXNmcY8fnPR2KS5qhI T4tA== X-Gm-Message-State: AIkVDXJ1pWR/D+lqJIeOG7wYTepKEJ/iceWLoZtr3yAOgB/lCZsBl+Y8F5z0zDJ2o3kDCA== X-Received: by 10.107.40.142 with SMTP id o136mr41989932ioo.1.1483295552816; Sun, 01 Jan 2017 10:32:32 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id g130sm21558798ita.10.2017.01.01.10.32.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 01 Jan 2017 10:32:31 -0800 (PST) From: npostavs@users.sourceforge.net References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> <87oa1fknx9.fsf@users.sourceforge.net> <83y40idqm3.fsf@gnu.org> Date: Sun, 01 Jan 2017 13:33:35 -0500 In-Reply-To: <83y40idqm3.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 17 Nov 2016 18:21:24 +0200") Message-ID: <87lguu7hq8.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Eli Zaretskii writes: >> >> /* Define MATCH_MAY_ALLOCATE unless we need to make sure that the >> searching and matching functions should not call alloca. On some >> systems, alloca is implemented in terms of malloc, and if we're >> using the relocating allocator routines, then malloc could cause a >> relocation, which might (if the strings being searched are in the >> ralloc heap) shift the data out from underneath the regexp >> routines. >> >> [...] > > The first part is not obsolete, but its reasoning is backwards: > SAFE_ALLOCA indeed can call malloc, but it could only cause relocation > if REGEX_MALLOC is defined (and ralloc.c is compiled in). And when > you define REGEX_MALLOC, MATCH_MAY_ALLOCATE is undefined. So the text > there should be revised. Is there ever any case where REGEX_MALLOC is defined? I can't see where it happens. I don't understand why you say relocation is dependent on REGEX_MALLOC, I thought only REL_ALLOC affects that. And since we added r_alloc_inhibit_buffer_relocation around the regex calls, aren't all these concerns about relocation obsolete? From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Jan 2017 18:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@users.sourceforge.net Cc: 24751@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.148329613622343 (code B ref 24751); Sun, 01 Jan 2017 18:43:02 +0000 Received: (at 24751) by debbugs.gnu.org; 1 Jan 2017 18:42:16 +0000 Received: from localhost ([127.0.0.1]:38785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNl5E-0005oJ-Is for submit@debbugs.gnu.org; Sun, 01 Jan 2017 13:42:16 -0500 Received: from eggs.gnu.org ([208.118.235.92]:57049) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNl5D-0005o6-Nv for 24751@debbugs.gnu.org; Sun, 01 Jan 2017 13:42:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNl55-0000h6-J0 for 24751@debbugs.gnu.org; Sun, 01 Jan 2017 13:42:10 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNl55-0000h1-F9; Sun, 01 Jan 2017 13:42:07 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2997 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cNl52-0001Ow-M9; Sun, 01 Jan 2017 13:42:07 -0500 Date: Sun, 01 Jan 2017 20:41:57 +0200 Message-Id: <83zijafwqy.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87lguu7hq8.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> <87oa1fknx9.fsf@users.sourceforge.net> <83y40idqm3.fsf@gnu.org> <87lguu7hq8.fsf@users.sourceforge.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > From: npostavs@users.sourceforge.net > Cc: 24751@debbugs.gnu.org > Date: Sun, 01 Jan 2017 13:33:35 -0500 > > Eli Zaretskii writes: > >> > >> /* Define MATCH_MAY_ALLOCATE unless we need to make sure that the > >> searching and matching functions should not call alloca. On some > >> systems, alloca is implemented in terms of malloc, and if we're > >> using the relocating allocator routines, then malloc could cause a > >> relocation, which might (if the strings being searched are in the > >> ralloc heap) shift the data out from underneath the regexp > >> routines. > >> > >> [...] > > > > The first part is not obsolete, but its reasoning is backwards: > > SAFE_ALLOCA indeed can call malloc, but it could only cause relocation > > if REGEX_MALLOC is defined (and ralloc.c is compiled in). And when > > you define REGEX_MALLOC, MATCH_MAY_ALLOCATE is undefined. So the text > > there should be revised. > > Is there ever any case where REGEX_MALLOC is defined? I can't see where > it happens. I don't understand the question. You can compile regex.c with the "-DREGEX_MALLOC" option whenever you like. We don't do that, but as long as the code which supports that is in regex.c, the comment goes with it. > I don't understand why you say relocation is dependent on > REGEX_MALLOC, I thought only REL_ALLOC affects that. REL_ALLOC determines whether ralloc.c is compiled in, which I mentioned above. > And since we added r_alloc_inhibit_buffer_relocation around the regex > calls, aren't all these concerns about relocation obsolete? The calls to r_alloc_inhibit_buffer_relocation are outside of regex.c, so the comments in regex.c don't know anything about that. From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Jan 2017 18:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24751@debbugs.gnu.org Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.148329697123586 (code B ref 24751); Sun, 01 Jan 2017 18:57:01 +0000 Received: (at 24751) by debbugs.gnu.org; 1 Jan 2017 18:56:11 +0000 Received: from localhost ([127.0.0.1]:38796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNlIg-00068L-Rr for submit@debbugs.gnu.org; Sun, 01 Jan 2017 13:56:11 -0500 Received: from mail-it0-f49.google.com ([209.85.214.49]:35024) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNlId-000688-U6 for 24751@debbugs.gnu.org; Sun, 01 Jan 2017 13:56:08 -0500 Received: by mail-it0-f49.google.com with SMTP id c20so262290052itb.0 for <24751@debbugs.gnu.org>; Sun, 01 Jan 2017 10:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=BYhiUdZqL5HvKNSuGCNny391IgJKqvyWoxsIhnVx9DU=; b=C1w6ota0xO/TaCVCZvV0hYKcLk5xTXrrQeG0kj5r6zeezDqi+zYE5OOv/SpB7Vf1dt PzvTztKJGzjSkGMsp/qTy4Lgn26W1JvWI0z0vqcsfzStTtcOG1Ct4DmlRcuebMujwuNp 0yi3ozlj0y/dEacFBxBv0a/ZGV22NBOkH6EhHbCFlTHRLYlV6VyyofaBlnd+vl5WSJ7v 8OWkeghiHsDIPqBDR7zcBcSqcVu5ahS9dH/NoVFKRiPNfAQ1j4FDaqTDtIocooy84zqx hzNjthAfAGBbF5315TZMwYpwwoKUca3LogeF8epl6W5PqKSij0X0rEKnPsHyJYa86eza lkUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=BYhiUdZqL5HvKNSuGCNny391IgJKqvyWoxsIhnVx9DU=; b=W6b9XUNHrfYjb16aEDwUO0kG46GUOOmefS9whg4f/HOlqlkTbnadeVeuBJtpkjbcf2 PqjZ4M0OJGF7JdcSNt6sGhy9DhkGplXrw0n9o+Ua1n8tMvKk3aDXp92D5DtZBL4DXbj4 2PsgQCY2aWartQs06TKqpEDyYQvO+urn4W3JFxspjzSX3vjbDY0YfvryG8vW0Zu4qk7J U0D4LDP1yfnMR2v2tvgUPOgXotuSmtFZDPScZ+z5iGiKhjainmDMs/6VWhapT3WrtFEr j8iEA9CcBgzDGi2smlHzF+u1SGKkhp/I/GhFY08gIdL9/mgYAlFtjmbwjQtoIRBIpWiF hN3Q== X-Gm-Message-State: AIkVDXIZiLn1lGuBf4wv2KP1hMFhGHo4Jietg032EhjgC53fG28/dxhcYnK7vBULJ/nCpA== X-Received: by 10.36.92.145 with SMTP id q139mr48519860itb.107.1483296962134; Sun, 01 Jan 2017 10:56:02 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id l3sm30697073ioa.7.2017.01.01.10.56.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 01 Jan 2017 10:56:01 -0800 (PST) From: npostavs@users.sourceforge.net References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> <87oa1fknx9.fsf@users.sourceforge.net> <83y40idqm3.fsf@gnu.org> <87lguu7hq8.fsf@users.sourceforge.net> <83zijafwqy.fsf@gnu.org> Date: Sun, 01 Jan 2017 13:57:05 -0500 In-Reply-To: <83zijafwqy.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 01 Jan 2017 20:41:57 +0200") Message-ID: <87inpy7gn2.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) Eli Zaretskii writes: >> From: npostavs@users.sourceforge.net >> Cc: 24751@debbugs.gnu.org >> Date: Sun, 01 Jan 2017 13:33:35 -0500 >> >> Eli Zaretskii writes: >> >> >> >> /* Define MATCH_MAY_ALLOCATE unless we need to make sure that the >> >> searching and matching functions should not call alloca. On some >> >> systems, alloca is implemented in terms of malloc, and if we're >> >> using the relocating allocator routines, then malloc could cause a >> >> relocation, which might (if the strings being searched are in the >> >> ralloc heap) shift the data out from underneath the regexp >> >> routines. >> >> >> >> [...] >> > >> > The first part is not obsolete, but its reasoning is backwards: >> > SAFE_ALLOCA indeed can call malloc, but it could only cause relocation >> > if REGEX_MALLOC is defined (and ralloc.c is compiled in). And when >> > you define REGEX_MALLOC, MATCH_MAY_ALLOCATE is undefined. So the text >> > there should be revised. >> >> Is there ever any case where REGEX_MALLOC is defined? I can't see where >> it happens. > > I don't understand the question. You can compile regex.c with the > "-DREGEX_MALLOC" option whenever you like. We don't do that, ^^^^^^^^^^^^^^^^ Thanks, that's what I was wondering about in my question. > >> I don't understand why you say relocation is dependent on >> REGEX_MALLOC, I thought only REL_ALLOC affects that. > > REL_ALLOC determines whether ralloc.c is compiled in, which I > mentioned above. But if REL_ALLOC is defined, then SAFE_ALLOCA could cause relocation (via malloc) regardless of whether REGEX_MALLOC is defined or not, no? From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Jan 2017 20:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@users.sourceforge.net Cc: 24751@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.148330124030173 (code B ref 24751); Sun, 01 Jan 2017 20:08:02 +0000 Received: (at 24751) by debbugs.gnu.org; 1 Jan 2017 20:07:20 +0000 Received: from localhost ([127.0.0.1]:38842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNmPX-0007qb-O2 for submit@debbugs.gnu.org; Sun, 01 Jan 2017 15:07:19 -0500 Received: from eggs.gnu.org ([208.118.235.92]:36967) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNmPV-0007qO-Da for 24751@debbugs.gnu.org; Sun, 01 Jan 2017 15:07:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNmPL-00078H-9O for 24751@debbugs.gnu.org; Sun, 01 Jan 2017 15:07:12 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59839) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNmPL-00078A-6M; Sun, 01 Jan 2017 15:07:07 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3210 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cNmPF-0004AS-B7; Sun, 01 Jan 2017 15:07:07 -0500 Date: Sun, 01 Jan 2017 22:06:54 +0200 Message-Id: <83tw9ifstd.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87inpy7gn2.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> <87oa1fknx9.fsf@users.sourceforge.net> <83y40idqm3.fsf@gnu.org> <87lguu7hq8.fsf@users.sourceforge.net> <83zijafwqy.fsf@gnu.org> <87inpy7gn2.fsf@users.sourceforge.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > From: npostavs@users.sourceforge.net > Cc: 24751@debbugs.gnu.org > Date: Sun, 01 Jan 2017 13:57:05 -0500 > > >> I don't understand why you say relocation is dependent on > >> REGEX_MALLOC, I thought only REL_ALLOC affects that. > > > > REL_ALLOC determines whether ralloc.c is compiled in, which I > > mentioned above. > > But if REL_ALLOC is defined, then SAFE_ALLOCA could cause relocation > (via malloc) regardless of whether REGEX_MALLOC is defined or not, no? Relocation as side effect of calling malloc only happens with buffer text. This is not what the comment in question alludes to. It alludes to this: /* Define how to allocate the failure stack. */ #if defined REL_ALLOC && defined REGEX_MALLOC # define REGEX_ALLOCATE_STACK(size) \ r_alloc (&failure_stack_ptr, (size)) # define REGEX_REALLOCATE_STACK(source, osize, nsize) \ r_re_alloc (&failure_stack_ptr, (nsize)) # define REGEX_FREE_STACK(ptr) \ r_alloc_free (&failure_stack_ptr) #else /* not using relocating allocator */ # define REGEX_ALLOCATE_STACK(size) REGEX_ALLOCATE (size) # define REGEX_REALLOCATE_STACK(source, o, n) REGEX_REALLOCATE (source, o, n) # define REGEX_FREE_STACK(ptr) REGEX_FREE (ptr) #endif /* not using relocating allocator */ This calls ralloc.c functions directly for allocating/reallocating the failure stack, when both REL_ALLOC and REGEX_MALLOC are defined. So the relocation in question is that of the failure stack, which won't happen if we call malloc, even if REL_ALLOC is defined, because only buffer text can be relocated when ralloc.c is called from malloc. From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Jan 2017 04:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24751@debbugs.gnu.org Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.148333253125013 (code B ref 24751); Mon, 02 Jan 2017 04:49:02 +0000 Received: (at 24751) by debbugs.gnu.org; 2 Jan 2017 04:48:51 +0000 Received: from localhost ([127.0.0.1]:38967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNuYF-0006VN-F6 for submit@debbugs.gnu.org; Sun, 01 Jan 2017 23:48:51 -0500 Received: from mail-io0-f172.google.com ([209.85.223.172]:36264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNuYD-0006V7-39 for 24751@debbugs.gnu.org; Sun, 01 Jan 2017 23:48:49 -0500 Received: by mail-io0-f172.google.com with SMTP id h133so169775335ioe.3 for <24751@debbugs.gnu.org>; Sun, 01 Jan 2017 20:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=SHhogUpWDJe+Kixr62Bwf4oONgmG0vWO9jhA0m6ZKYQ=; b=VpPS9Ebe9rBiMTs9+Z/0PoT1t7QykbDDarUVJ3vBq7Hjv0N6PPS0HuccfOq1cFrqz7 4WOWgCACnMWInphFLiwWY09PX57we6Qx0k0NiOjK4ohsORuFx/sr4uKKDX09enIEp5FL xtW02vVUyD5mRA4JoeOdLjwlrZYYjwFJpqZzDstJY0GQnfvHfYktUMxd2M2aDUN1Gcd7 PUMiMjhCiUusgejitr4+UBG6QV26C8ASNjDDGC0LuM78mwI2jW+CFZ6QvgW+ziiWVM0N hXvgDmLI2oK6MRDDUJ509Yzs9q9GjbutH2nn/hs0/G6LMvhzct97/lWYFEpJmQukgCtm YTZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=SHhogUpWDJe+Kixr62Bwf4oONgmG0vWO9jhA0m6ZKYQ=; b=J9+4FnP9jUIi+d48OsxMePypEHtG9IwmK/DA13E7uqLseHplsnaSry94P6Ztgw4CNX v4SvMWSHGLhFncy5nYPj0GzhFPkhgWBliSwihehAzFP4LjkM0aHUdk+cqz7Msg2NGLjX pfV+82WjbgwbGOLHxmX0Us6O55LSTQz6PadTA/zSfYrkDmYBvV8gKJNm/E+4KfCD7+qO jidYG40jvhJ29qjD01qs53CaZ7cuDky5ohYGaWqWEN9hUrBh/UkghmMM2UnXvVYxD3w7 tFbio6GVEhXv2MBJIyxE+BxCxhb2MB+53xxxxN2I9bdIbeoWaQmvbFHVRn+TtiD6IiMZ QXyQ== X-Gm-Message-State: AIkVDXIUxISfGNtk6H/xy1qagENth82sUBimFYmcsd5nuufxEvx92kLq2qr8kITb13POMg== X-Received: by 10.107.24.196 with SMTP id 187mr43124503ioy.81.1483332523513; Sun, 01 Jan 2017 20:48:43 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id n3sm30037052itb.2.2017.01.01.20.48.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 01 Jan 2017 20:48:42 -0800 (PST) From: npostavs@users.sourceforge.net References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> <87oa1fknx9.fsf@users.sourceforge.net> <83y40idqm3.fsf@gnu.org> Date: Sun, 01 Jan 2017 23:49:46 -0500 In-Reply-To: <83y40idqm3.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 17 Nov 2016 18:21:24 +0200") Message-ID: <877f6e6p79.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> >> /* Define MATCH_MAY_ALLOCATE unless we need to make sure that the >> searching and matching functions should not call alloca. On some >> systems, alloca is implemented in terms of malloc, and if we're >> using the relocating allocator routines, then malloc could cause a >> relocation, which might (if the strings being searched are in the >> ralloc heap) shift the data out from underneath the regexp >> routines. > > > The first part is not obsolete, but its reasoning is backwards: > SAFE_ALLOCA indeed can call malloc, but it could only cause relocation > if REGEX_MALLOC is defined (and ralloc.c is compiled in). And when > you define REGEX_MALLOC, MATCH_MAY_ALLOCATE is undefined. So the text > there should be revised. Everything you've said makes sense after your last message, but I'm still unable to put it together and come up with a revised comment. Could you make a suggestion? Here are the rest of the changes. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v1-0001-Use-expanded-stack-during-regex-matches.patch Content-Description: patch >From 60e43d62735b212738584da0631c8efc768084c5 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sun, 1 Jan 2017 14:09:13 -0500 Subject: [PATCH v1] Use expanded stack during regex matches While the stack is increased in main(), to allow the regex stack allocation to use alloca we also need to modify regex.c to actually take advantage of the increased stack, and not limit stack allocations to SAFE_ALLOCA bytes. * src/regex.c (MATCH_MAY_ALLOCATE): Remove obsolete comment about allocations in signal handlers which no longer happens. (emacs_re_safe_alloca): New variable. (REGEX_USE_SAFE_ALLOCA): Use it as the limit of stack allocation instead of MAX_ALLOCA. (emacs_re_max_failures): Rename from `re_max_failures' to avoid confusion the glibc's `re_max_failures'. * src/emacs.c (main): Increase the amount of fixed 'extra' bytes we add to the stack. Instead of changing emacs_re_max_failures based on the new stack size, just change emacs_re_safe_alloca; emacs_re_max_failures remains constant regardless, since if we run out stack space SAFE_ALLOCA will fall back to heap allocation. --- src/emacs.c | 21 ++++++++++++--------- src/regex.c | 44 ++++++++++++++++++++++---------------------- src/regex.h | 7 ++++++- 3 files changed, 40 insertions(+), 32 deletions(-) diff --git a/src/emacs.c b/src/emacs.c index ae29e9a..cb6b503 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -831,14 +831,16 @@ main (int argc, char **argv) rlim_t lim = rlim.rlim_cur; /* Approximate the amount regex.c needs per unit of - re_max_failures, then add 33% to cover the size of the + emacs_re_max_failures, then add 33% to cover the size of the smaller stacks that regex.c successively allocates and discards on its way to the maximum. */ - int ratio = 20 * sizeof (char *); - ratio += ratio / 3; + int min_ratio = 20 * sizeof (char *); + int ratio = min_ratio + min_ratio / 3; - /* Extra space to cover what we're likely to use for other reasons. */ - int extra = 200000; + /* Extra space to cover what we're likely to use for other + reasons. For example, a typical GC might take 30K stack + frames. */ + int extra = (30 * 1000) * 50; bool try_to_grow_stack = true; #ifndef CANNOT_DUMP @@ -847,7 +849,7 @@ main (int argc, char **argv) if (try_to_grow_stack) { - rlim_t newlim = re_max_failures * ratio + extra; + rlim_t newlim = emacs_re_max_failures * ratio + extra; /* Round the new limit to a page boundary; this is needed for Darwin kernel 15.4.0 (see Bug#23622) and perhaps @@ -869,9 +871,10 @@ main (int argc, char **argv) lim = newlim; } } - - /* Don't let regex.c overflow the stack. */ - re_max_failures = lim < extra ? 0 : min (lim - extra, SIZE_MAX) / ratio; + /* Let regex.c use more stack, if available. */ + emacs_re_safe_alloca = max + (min (lim - extra, SIZE_MAX) * (min_ratio / ratio), + MAX_ALLOCA); } #endif /* HAVE_SETRLIMIT and RLIMIT_STACK and not CYGWIN */ diff --git a/src/regex.c b/src/regex.c index a2d2c52..adf2fa1 100644 --- a/src/regex.c +++ b/src/regex.c @@ -430,9 +430,12 @@ init_syntax_once (void) /* Should we use malloc or alloca? If REGEX_MALLOC is not defined, we use `alloca' instead of `malloc'. This is because using malloc in - re_search* or re_match* could cause memory leaks when C-g is used in - Emacs; also, malloc is slower and causes storage fragmentation. On - the other hand, malloc is more portable, and easier to debug. + re_search* or re_match* could cause memory leaks when C-g is used + in Emacs (note that SAFE_ALLOCA could also call malloc, but does so + via `record_xmalloc' which uses `unwind_protect' to ensure the + memory is freed even in case of non-local exits); also, malloc is + slower and causes storage fragmentation. On the other hand, malloc + is more portable, and easier to debug. Because we sometimes use alloca, some routines have to be macros, not functions -- `alloca'-allocated space disappears at the end of the @@ -447,7 +450,13 @@ init_syntax_once (void) #else /* not REGEX_MALLOC */ # ifdef emacs -# define REGEX_USE_SAFE_ALLOCA USE_SAFE_ALLOCA +/* This may be adjusted in main(), if the stack is successfully grown. */ +ptrdiff_t emacs_re_safe_alloca = MAX_ALLOCA; +/* Like USE_SAFE_ALLOCA, but use emacs_re_safe_alloca. */ +# define REGEX_USE_SAFE_ALLOCA \ + ptrdiff_t sa_avail = emacs_re_safe_alloca; \ + ptrdiff_t sa_count = SPECPDL_INDEX (); bool sa_must_free = false + # define REGEX_SAFE_FREE() SAFE_FREE () # define REGEX_ALLOCATE SAFE_ALLOCA # else @@ -1203,16 +1212,7 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) using the relocating allocator routines, then malloc could cause a relocation, which might (if the strings being searched are in the ralloc heap) shift the data out from underneath the regexp - routines. - - Here's another reason to avoid allocation: Emacs - processes input from X in a signal handler; processing X input may - call malloc; if input arrives while a matching routine is calling - malloc, then we're scrod. But Emacs can't just block input while - calling matching routines; then we don't notice interrupts when - they come in. So, Emacs blocks input around all regexp calls - except the matching calls, which it leaves unprotected, in the - faith that they will not malloc. */ + routines. */ /* Normally, this is fine. */ #define MATCH_MAY_ALLOCATE @@ -1249,9 +1249,9 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) whose default stack limit is 2mb. In order for a larger value to work reliably, you have to try to make it accord with the process stack limit. */ -size_t re_max_failures = 40000; +size_t emacs_re_max_failures = 40000; # else -size_t re_max_failures = 4000; +size_t emacs_re_max_failures = 4000; # endif union fail_stack_elt @@ -1304,7 +1304,7 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) /* Double the size of FAIL_STACK, up to a limit - which allows approximately `re_max_failures' items. + which allows approximately `emacs_re_max_failures' items. Return 1 if succeeds, and 0 if either ran out of memory allocating space for it or it was already too large. @@ -1319,19 +1319,19 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) #define FAIL_STACK_GROWTH_FACTOR 4 #define GROW_FAIL_STACK(fail_stack) \ - (((fail_stack).size >= re_max_failures * TYPICAL_FAILURE_SIZE) \ + (((fail_stack).size >= emacs_re_max_failures * TYPICAL_FAILURE_SIZE) \ ? 0 \ : ((fail_stack).stack \ = REGEX_REALLOCATE_STACK ((fail_stack).stack, \ (fail_stack).size * sizeof (fail_stack_elt_t), \ - min (re_max_failures * TYPICAL_FAILURE_SIZE, \ + min (emacs_re_max_failures * TYPICAL_FAILURE_SIZE, \ ((fail_stack).size * FAIL_STACK_GROWTH_FACTOR)) \ * sizeof (fail_stack_elt_t)), \ \ (fail_stack).stack == NULL \ ? 0 \ : ((fail_stack).size \ - = (min (re_max_failures * TYPICAL_FAILURE_SIZE, \ + = (min (emacs_re_max_failures * TYPICAL_FAILURE_SIZE, \ ((fail_stack).size * FAIL_STACK_GROWTH_FACTOR))), \ 1))) @@ -3638,9 +3638,9 @@ regex_compile (const_re_char *pattern, size_t size, { int num_regs = bufp->re_nsub + 1; - if (fail_stack.size < re_max_failures * TYPICAL_FAILURE_SIZE) + if (fail_stack.size < emacs_re_max_failures * TYPICAL_FAILURE_SIZE) { - fail_stack.size = re_max_failures * TYPICAL_FAILURE_SIZE; + fail_stack.size = emacs_re_max_failures * TYPICAL_FAILURE_SIZE; falk_stack.stack = realloc (fail_stack.stack, fail_stack.size * sizeof *falk_stack.stack); } diff --git a/src/regex.h b/src/regex.h index 34c9929..1d439de 100644 --- a/src/regex.h +++ b/src/regex.h @@ -186,7 +186,12 @@ #endif /* Roughly the maximum number of failure points on the stack. */ -extern size_t re_max_failures; +extern size_t emacs_re_max_failures; + +#ifdef emacs +/* Amount of memory that we can safely stack allocate. */ +extern ptrdiff_t emacs_re_safe_alloca; +#endif /* Define combinations of the above bits for the standard possibilities. -- 2.9.3 --=-=-=-- From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Jan 2017 15:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@users.sourceforge.net Cc: 24751@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.148337067230837 (code B ref 24751); Mon, 02 Jan 2017 15:25:01 +0000 Received: (at 24751) by debbugs.gnu.org; 2 Jan 2017 15:24:32 +0000 Received: from localhost ([127.0.0.1]:39479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cO4TQ-00081J-CY for submit@debbugs.gnu.org; Mon, 02 Jan 2017 10:24:32 -0500 Received: from eggs.gnu.org ([208.118.235.92]:46036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cO4TO-000816-KJ for 24751@debbugs.gnu.org; Mon, 02 Jan 2017 10:24:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cO4TG-0001qP-7k for 24751@debbugs.gnu.org; Mon, 02 Jan 2017 10:24:25 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cO4TG-0001qL-41; Mon, 02 Jan 2017 10:24:22 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4406 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cO4TD-0003OQ-ET; Mon, 02 Jan 2017 10:24:21 -0500 Date: Mon, 02 Jan 2017 17:24:26 +0200 Message-Id: <83r34lfpsl.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <877f6e6p79.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> <87oa1fknx9.fsf@users.sourceforge.net> <83y40idqm3.fsf@gnu.org> <877f6e6p79.fsf@users.sourceforge.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > From: npostavs@users.sourceforge.net > Cc: 24751@debbugs.gnu.org > Date: Sun, 01 Jan 2017 23:49:46 -0500 > > Everything you've said makes sense after your last message, but I'm > still unable to put it together and come up with a revised comment. > Could you make a suggestion? How about the below? --- src/regex.c~0 2016-12-11 06:39:19.000000000 +0200 +++ src/regex.c 2017-01-02 12:40:44.266517100 +0200 @@ -1195,24 +1195,28 @@ gettext_noop ("Range striding over charsets") /* REG_ERANGEX */ }; -/* Avoiding alloca during matching, to placate r_alloc. */ +/* Whether to allocate memory during matching. */ -/* Define MATCH_MAY_ALLOCATE unless we need to make sure that the - searching and matching functions should not call alloca. On some - systems, alloca is implemented in terms of malloc, and if we're - using the relocating allocator routines, then malloc could cause a - relocation, which might (if the strings being searched are in the - ralloc heap) shift the data out from underneath the regexp - routines. - - Here's another reason to avoid allocation: Emacs - processes input from X in a signal handler; processing X input may - call malloc; if input arrives while a matching routine is calling - malloc, then we're scrod. But Emacs can't just block input while - calling matching routines; then we don't notice interrupts when - they come in. So, Emacs blocks input around all regexp calls - except the matching calls, which it leaves unprotected, in the - faith that they will not malloc. */ +/* Define MATCH_MAY_ALLOCATE to allow the searching and matching + functions allocate memory for the failure stack and registers. + Normally should be defined, because otherwise searching and + matching routines will have much smaller memory resources at their + disposal, and therefore might fail to handle complex regexps. + Therefore undefine MATCH_MAY_ALLOCATE only in the following + exceptional situations: + + . When running on a system where memory is at premium. + . When alloca cannot be used at all, perhaps due to bugs in + its implementation, or its being unavailable, or due to a + very small stack size. This requires to define REGEX_MALLOC + to use malloc instead, which in turn could lead to memory + leaks if search is interrupted by a signal. (For these + reasons, defining REGEX_MALLOC when building Emacs + automatically undefines MATCH_MAY_ALLOCATE, but outside + Emacs you may not care about memory leaks.) If you want to + prevent the memory leaks, undefine MATCH_MAY_ALLOCATE. + . When code that calls the searching and matching functions + cannot allow memory allocation, for whatever reasons. */ /* Normally, this is fine. */ #define MATCH_MAY_ALLOCATE From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Jan 2017 18:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24751@debbugs.gnu.org Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.148338177121598 (code B ref 24751); Mon, 02 Jan 2017 18:30:03 +0000 Received: (at 24751) by debbugs.gnu.org; 2 Jan 2017 18:29:31 +0000 Received: from localhost ([127.0.0.1]:39653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cO7MQ-0005cI-FB for submit@debbugs.gnu.org; Mon, 02 Jan 2017 13:29:30 -0500 Received: from mail-io0-f173.google.com ([209.85.223.173]:34799) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cO7MP-0005c4-2h for 24751@debbugs.gnu.org; Mon, 02 Jan 2017 13:29:29 -0500 Received: by mail-io0-f173.google.com with SMTP id p42so416840172ioo.1 for <24751@debbugs.gnu.org>; Mon, 02 Jan 2017 10:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=yHTrb/qxHMtnhhTLPkvmxrxvCdKm8sGQUrToZCfCzqA=; b=bU/3mVGXfIHuuc4C31Bm8rt+TMejmm9RwDL1rn80S2TA2GyitoSyBg271DXwV+9S8i kSLnUA5EgiD/nwIczuRqwbwQpuh960z2wpbACNjqgDBfTa8VJS6slsRgKFe8JSxCsIHW viSMQYaYqm/41oW6lxLd0jBPpt+8DWd7UalPojhCat1/dHfwq1BcOab0IQi4FcNZkE28 bySo5PfgKNyejVNAcZVMzZCm3HeJi6fwJS5JmX2ZGugAKH4Szk3LRe/TWy/bIcNy2qC2 7E4Kgx/gdMaWFDS5xwzirgkM/6u1uw8pJEy0y7+FbiWYntrFMrw6ZRWzzItqfEUJ8wZo mYDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=yHTrb/qxHMtnhhTLPkvmxrxvCdKm8sGQUrToZCfCzqA=; b=m+fHamaDkNyON5jR9LzCEk2xaqbP+nScnTo/kubwJYOGTc+xeEzdviosoM1GWg+BcH e8Do2VcJmKXljytxflMSIylOe2i7/3BKnnqbA2xGmIdFS4Qi47zu3k3URAd1OPBmEI+O FdfWpg9sWzw+mrITl3XMXmVTlR1iadS6qOcKflDlbyBn396LeDx3T/poqKp9f7HJ70K+ WJ7Ke4RU2I8etRkKreawOCqaCynSNe86lFuocWzTBkXbE59fgsc8YXilvX/Pa9zwe9Na 9XNHJie4Clk9y7z3M5zrra5HvRc3iFAB53qoO4MsOfdsz20S5ePs+WR7wbknTL4itcDh HrjQ== X-Gm-Message-State: AIkVDXLXNLNOrIjJi6oOvgEypGJci3BVjt465PLzBEWXp1cH40QDhZm6ntndd716rqPZAg== X-Received: by 10.107.173.164 with SMTP id m36mr43716565ioo.186.1483381763191; Mon, 02 Jan 2017 10:29:23 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id g186sm30957100itb.21.2017.01.02.10.29.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 02 Jan 2017 10:29:22 -0800 (PST) From: npostavs@users.sourceforge.net References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> <87oa1fknx9.fsf@users.sourceforge.net> <83y40idqm3.fsf@gnu.org> <877f6e6p79.fsf@users.sourceforge.net> <83r34lfpsl.fsf@gnu.org> Date: Mon, 02 Jan 2017 13:30:26 -0500 In-Reply-To: <83r34lfpsl.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 02 Jan 2017 17:24:26 +0200") Message-ID: <8737h171rx.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: npostavs@users.sourceforge.net >> Cc: 24751@debbugs.gnu.org >> Date: Sun, 01 Jan 2017 23:49:46 -0500 >> >> Everything you've said makes sense after your last message, but I'm >> still unable to put it together and come up with a revised comment. >> Could you make a suggestion? > > How about the below? Looks good, I've incorporated it into the patch: --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v3-0001-Fix-computation-of-regex-stack-limit.patch Content-Description: patch >From 188801f8e017f0702cbb24390e4f88b3d0da18ff Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sat, 5 Nov 2016 16:51:53 -0400 Subject: [PATCH v3 1/2] Fix computation of regex stack limit The regex stack limit was being computed as the number of stack entries, whereas it was being compared with the current size as measured in bytes. This could cause indefinite looping when nearing the stack limit if re_max_failures happened not to be a multiple of sizeof fail_stack_elt_t (Bug #24751). * src/regex.c (GROW_FAIL_STACK): Compute both current stack size and limit as numbers of stack entries. --- src/regex.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/src/regex.c b/src/regex.c index ae3fde8..a2d2c52 100644 --- a/src/regex.c +++ b/src/regex.c @@ -1319,23 +1319,20 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) #define FAIL_STACK_GROWTH_FACTOR 4 #define GROW_FAIL_STACK(fail_stack) \ - (((fail_stack).size * sizeof (fail_stack_elt_t) \ - >= re_max_failures * TYPICAL_FAILURE_SIZE) \ + (((fail_stack).size >= re_max_failures * TYPICAL_FAILURE_SIZE) \ ? 0 \ : ((fail_stack).stack \ = REGEX_REALLOCATE_STACK ((fail_stack).stack, \ (fail_stack).size * sizeof (fail_stack_elt_t), \ - min (re_max_failures * TYPICAL_FAILURE_SIZE, \ - ((fail_stack).size * sizeof (fail_stack_elt_t) \ - * FAIL_STACK_GROWTH_FACTOR))), \ + min (re_max_failures * TYPICAL_FAILURE_SIZE, \ + ((fail_stack).size * FAIL_STACK_GROWTH_FACTOR)) \ + * sizeof (fail_stack_elt_t)), \ \ (fail_stack).stack == NULL \ ? 0 \ : ((fail_stack).size \ - = (min (re_max_failures * TYPICAL_FAILURE_SIZE, \ - ((fail_stack).size * sizeof (fail_stack_elt_t) \ - * FAIL_STACK_GROWTH_FACTOR)) \ - / sizeof (fail_stack_elt_t)), \ + = (min (re_max_failures * TYPICAL_FAILURE_SIZE, \ + ((fail_stack).size * FAIL_STACK_GROWTH_FACTOR))), \ 1))) -- 2.9.3 --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v3-0002-Use-expanded-stack-during-regex-matches.patch Content-Description: patch >From 76656125620b442c4895c8460a0fe7c5298b3fa6 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sun, 1 Jan 2017 14:09:13 -0500 Subject: [PATCH v3 2/2] Use expanded stack during regex matches While the stack is increased in main(), to allow the regex stack allocation to use alloca we also need to modify regex.c to actually take advantage of the increased stack, and not limit stack allocations to SAFE_ALLOCA bytes. * src/regex.c (MATCH_MAY_ALLOCATE): Remove obsolete comment about allocations in signal handlers which no longer happens and correct description about when and why MATCH_MAY_ALLOCATE should be defined. (emacs_re_safe_alloca): New variable. (REGEX_USE_SAFE_ALLOCA): Use it as the limit of stack allocation instead of MAX_ALLOCA. (emacs_re_max_failures): Rename from `re_max_failures' to avoid confusion with glibc's `re_max_failures'. * src/emacs.c (main): Increase the amount of fixed 'extra' bytes we add to the stack. Instead of changing emacs_re_max_failures based on the new stack size, just change emacs_re_safe_alloca; emacs_re_max_failures remains constant regardless, since if we run out stack space SAFE_ALLOCA will fall back to heap allocation. Co-authored-by: Eli Zaretskii --- src/emacs.c | 22 +++++++++++-------- src/regex.c | 73 ++++++++++++++++++++++++++++++++++++------------------------- src/regex.h | 7 +++++- 3 files changed, 62 insertions(+), 40 deletions(-) diff --git a/src/emacs.c b/src/emacs.c index ae29e9a..28b395c 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -831,14 +831,16 @@ main (int argc, char **argv) rlim_t lim = rlim.rlim_cur; /* Approximate the amount regex.c needs per unit of - re_max_failures, then add 33% to cover the size of the + emacs_re_max_failures, then add 33% to cover the size of the smaller stacks that regex.c successively allocates and discards on its way to the maximum. */ - int ratio = 20 * sizeof (char *); - ratio += ratio / 3; + int min_ratio = 20 * sizeof (char *); + int ratio = min_ratio + min_ratio / 3; - /* Extra space to cover what we're likely to use for other reasons. */ - int extra = 200000; + /* Extra space to cover what we're likely to use for other + reasons. For example, a typical GC might take 30K stack + frames. */ + int extra = (30 * 1000) * 50; bool try_to_grow_stack = true; #ifndef CANNOT_DUMP @@ -847,7 +849,7 @@ main (int argc, char **argv) if (try_to_grow_stack) { - rlim_t newlim = re_max_failures * ratio + extra; + rlim_t newlim = emacs_re_max_failures * ratio + extra; /* Round the new limit to a page boundary; this is needed for Darwin kernel 15.4.0 (see Bug#23622) and perhaps @@ -869,9 +871,11 @@ main (int argc, char **argv) lim = newlim; } } - - /* Don't let regex.c overflow the stack. */ - re_max_failures = lim < extra ? 0 : min (lim - extra, SIZE_MAX) / ratio; + /* 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); } #endif /* HAVE_SETRLIMIT and RLIMIT_STACK and not CYGWIN */ diff --git a/src/regex.c b/src/regex.c index a2d2c52..5ebcda1 100644 --- a/src/regex.c +++ b/src/regex.c @@ -430,9 +430,12 @@ init_syntax_once (void) /* Should we use malloc or alloca? If REGEX_MALLOC is not defined, we use `alloca' instead of `malloc'. This is because using malloc in - re_search* or re_match* could cause memory leaks when C-g is used in - Emacs; also, malloc is slower and causes storage fragmentation. On - the other hand, malloc is more portable, and easier to debug. + re_search* or re_match* could cause memory leaks when C-g is used + in Emacs (note that SAFE_ALLOCA could also call malloc, but does so + via `record_xmalloc' which uses `unwind_protect' to ensure the + memory is freed even in case of non-local exits); also, malloc is + slower and causes storage fragmentation. On the other hand, malloc + is more portable, and easier to debug. Because we sometimes use alloca, some routines have to be macros, not functions -- `alloca'-allocated space disappears at the end of the @@ -447,7 +450,13 @@ init_syntax_once (void) #else /* not REGEX_MALLOC */ # ifdef emacs -# define REGEX_USE_SAFE_ALLOCA USE_SAFE_ALLOCA +/* This may be adjusted in main(), if the stack is successfully grown. */ +ptrdiff_t emacs_re_safe_alloca = MAX_ALLOCA; +/* Like USE_SAFE_ALLOCA, but use emacs_re_safe_alloca. */ +# define REGEX_USE_SAFE_ALLOCA \ + ptrdiff_t sa_avail = emacs_re_safe_alloca; \ + ptrdiff_t sa_count = SPECPDL_INDEX (); bool sa_must_free = false + # define REGEX_SAFE_FREE() SAFE_FREE () # define REGEX_ALLOCATE SAFE_ALLOCA # else @@ -1195,24 +1204,28 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) gettext_noop ("Range striding over charsets") /* REG_ERANGEX */ }; -/* Avoiding alloca during matching, to placate r_alloc. */ - -/* Define MATCH_MAY_ALLOCATE unless we need to make sure that the - searching and matching functions should not call alloca. On some - systems, alloca is implemented in terms of malloc, and if we're - using the relocating allocator routines, then malloc could cause a - relocation, which might (if the strings being searched are in the - ralloc heap) shift the data out from underneath the regexp - routines. - - Here's another reason to avoid allocation: Emacs - processes input from X in a signal handler; processing X input may - call malloc; if input arrives while a matching routine is calling - malloc, then we're scrod. But Emacs can't just block input while - calling matching routines; then we don't notice interrupts when - they come in. So, Emacs blocks input around all regexp calls - except the matching calls, which it leaves unprotected, in the - faith that they will not malloc. */ +/* Whether to allocate memory during matching. */ + +/* Define MATCH_MAY_ALLOCATE to allow the searching and matching + functions allocate memory for the failure stack and registers. + Normally should be defined, because otherwise searching and + matching routines will have much smaller memory resources at their + disposal, and therefore might fail to handle complex regexps. + Therefore undefine MATCH_MAY_ALLOCATE only in the following + exceptional situations: + + . When running on a system where memory is at premium. + . When alloca cannot be used at all, perhaps due to bugs in + its implementation, or its being unavailable, or due to a + very small stack size. This requires to define REGEX_MALLOC + to use malloc instead, which in turn could lead to memory + leaks if search is interrupted by a signal. (For these + reasons, defining REGEX_MALLOC when building Emacs + automatically undefines MATCH_MAY_ALLOCATE, but outside + Emacs you may not care about memory leaks.) If you want to + prevent the memory leaks, undefine MATCH_MAY_ALLOCATE. + . When code that calls the searching and matching functions + cannot allow memory allocation, for whatever reasons. */ /* Normally, this is fine. */ #define MATCH_MAY_ALLOCATE @@ -1249,9 +1262,9 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) whose default stack limit is 2mb. In order for a larger value to work reliably, you have to try to make it accord with the process stack limit. */ -size_t re_max_failures = 40000; +size_t emacs_re_max_failures = 40000; # else -size_t re_max_failures = 4000; +size_t emacs_re_max_failures = 4000; # endif union fail_stack_elt @@ -1304,7 +1317,7 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) /* Double the size of FAIL_STACK, up to a limit - which allows approximately `re_max_failures' items. + which allows approximately `emacs_re_max_failures' items. Return 1 if succeeds, and 0 if either ran out of memory allocating space for it or it was already too large. @@ -1319,19 +1332,19 @@ WEAK_ALIAS (__re_set_syntax, re_set_syntax) #define FAIL_STACK_GROWTH_FACTOR 4 #define GROW_FAIL_STACK(fail_stack) \ - (((fail_stack).size >= re_max_failures * TYPICAL_FAILURE_SIZE) \ + (((fail_stack).size >= emacs_re_max_failures * TYPICAL_FAILURE_SIZE) \ ? 0 \ : ((fail_stack).stack \ = REGEX_REALLOCATE_STACK ((fail_stack).stack, \ (fail_stack).size * sizeof (fail_stack_elt_t), \ - min (re_max_failures * TYPICAL_FAILURE_SIZE, \ + min (emacs_re_max_failures * TYPICAL_FAILURE_SIZE, \ ((fail_stack).size * FAIL_STACK_GROWTH_FACTOR)) \ * sizeof (fail_stack_elt_t)), \ \ (fail_stack).stack == NULL \ ? 0 \ : ((fail_stack).size \ - = (min (re_max_failures * TYPICAL_FAILURE_SIZE, \ + = (min (emacs_re_max_failures * TYPICAL_FAILURE_SIZE, \ ((fail_stack).size * FAIL_STACK_GROWTH_FACTOR))), \ 1))) @@ -3638,9 +3651,9 @@ regex_compile (const_re_char *pattern, size_t size, { int num_regs = bufp->re_nsub + 1; - if (fail_stack.size < re_max_failures * TYPICAL_FAILURE_SIZE) + if (fail_stack.size < emacs_re_max_failures * TYPICAL_FAILURE_SIZE) { - fail_stack.size = re_max_failures * TYPICAL_FAILURE_SIZE; + fail_stack.size = emacs_re_max_failures * TYPICAL_FAILURE_SIZE; falk_stack.stack = realloc (fail_stack.stack, fail_stack.size * sizeof *falk_stack.stack); } diff --git a/src/regex.h b/src/regex.h index 34c9929..1d439de 100644 --- a/src/regex.h +++ b/src/regex.h @@ -186,7 +186,12 @@ #endif /* Roughly the maximum number of failure points on the stack. */ -extern size_t re_max_failures; +extern size_t emacs_re_max_failures; + +#ifdef emacs +/* Amount of memory that we can safely stack allocate. */ +extern ptrdiff_t emacs_re_safe_alloca; +#endif /* Define combinations of the above bits for the standard possibilities. -- 2.9.3 --=-=-=-- From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Jan 2017 19:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: npostavs@users.sourceforge.net Cc: 24751@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.148338495426212 (code B ref 24751); Mon, 02 Jan 2017 19:23:01 +0000 Received: (at 24751) by debbugs.gnu.org; 2 Jan 2017 19:22:34 +0000 Received: from localhost ([127.0.0.1]:39680 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cO8Bl-0006oi-VH for submit@debbugs.gnu.org; Mon, 02 Jan 2017 14:22:34 -0500 Received: from eggs.gnu.org ([208.118.235.92]:35325) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cO8Bk-0006oU-Im for 24751@debbugs.gnu.org; Mon, 02 Jan 2017 14:22:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cO8Bc-0006EF-8o for 24751@debbugs.gnu.org; Mon, 02 Jan 2017 14:22:27 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cO8Bc-0006E9-5N; Mon, 02 Jan 2017 14:22:24 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4913 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cO8Ba-0000Dw-Qw; Mon, 02 Jan 2017 14:22:23 -0500 Date: Mon, 02 Jan 2017 21:22:28 +0200 Message-Id: <83inpxferv.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <8737h171rx.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> <87oa1fknx9.fsf@users.sourceforge.net> <83y40idqm3.fsf@gnu.org> <877f6e6p79.fsf@users.sourceforge.net> <83r34lfpsl.fsf@gnu.org> <8737h171rx.fsf@users.sourceforge.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.2 (--------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.2 (--------) > From: npostavs@users.sourceforge.net > Cc: 24751@debbugs.gnu.org > Date: Mon, 02 Jan 2017 13:30:26 -0500 > > > How about the below? > > Looks good, I've incorporated it into the patch: Fine with me, thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 02 16:58:22 2017 Received: (at control) by debbugs.gnu.org; 2 Jan 2017 21:58:22 +0000 Received: from localhost ([127.0.0.1]:39766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOAcX-0001y4-Ra for submit@debbugs.gnu.org; Mon, 02 Jan 2017 16:58:22 -0500 Received: from mail-it0-f44.google.com ([209.85.214.44]:37956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOAcW-0001xm-Fl for control@debbugs.gnu.org; Mon, 02 Jan 2017 16:58:21 -0500 Received: by mail-it0-f44.google.com with SMTP id x2so284564607itf.1 for ; Mon, 02 Jan 2017 13:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:subject:date:message-id:mime-version; bh=BLGARD4+q8W+aWrU4SOwEoe+GCQOQHRRTNZoSAp1jTQ=; b=kGPaZpy/J8JjEvfUivSRzSqU/bhs3uBXdL8Yhd1qGdJCAhlZBnmRnV88FqfsUfkc2Z WLkdW0AiHdQEBGcrr0UX1LW9/b3iApYlt8OLTlruQQgJWOKCy5TqqI2LBeyN5bbVfbPy vZ/gjnS2Ynsa1/2bZo/tGV+81ec+3BittsFwWhvNbo2Dn0kfGdInktLbO/J8rAOA8LbL 7addG6sauVsAS1NmrmhacPIeHUcdqe+Wvdbh+YohehNPzhihceU1pcm73JcOlNuNbPhw iZiR/NBBazC4TUa7hd85d9cbVDPEnABD+KNG5+ho1tuKuXTgR/mW4X/BpKGgUp2nQewg KirA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version; bh=BLGARD4+q8W+aWrU4SOwEoe+GCQOQHRRTNZoSAp1jTQ=; b=gjUBhbJt+pK8ztVCIxDK5RHaS75qVI2u4B0CTfq5YefDHo34d6V+8ZBL1Ykxa1VGDD RnXyHd/lVCfezLtmhssWozVOcyoKxAOi+mpiGLiu0MYW03fgL3O8lBQTWpkVtjgcz7Gc mzmHmNleArNwfFh+q6tmsExwwH7VpUUT+RhSA5Nq6/Za45jQOgFOJ/Kpy2IGXCkeznoK KZ9p7HsBqZrzDLuY7QbWowRpEIaWkpjCcikfmbEWe0xfDu4BwdSF21+5ATh6GVSLGI90 w87d5u4YLd1dKV07OwQqMIFv1MQm7h9aKj6XwvSjjLaoKk1gD0WV/lrBANl8/8NqQjgQ Vfvg== X-Gm-Message-State: AIkVDXL3n7DT+JX4OYC0EyZ2GUT+ui1W00pHp1rNV9r8iPWm+X1TEPFGtSKKTB32baS5dg== X-Received: by 10.36.29.19 with SMTP id 19mr49333052itj.101.1483394294718; Mon, 02 Jan 2017 13:58:14 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id l203sm31334280ita.6.2017.01.02.13.58.14 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 02 Jan 2017 13:58:14 -0800 (PST) From: npostavs@users.sourceforge.net To: control@debbugs.gnu.org Subject: control message for bug #24751 Date: Mon, 02 Jan 2017 16:59:18 -0500 Message-ID: <87vatx5djd.fsf@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) tags 24751 patch quit From unknown Mon Aug 18 19:31:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Jan 2017 23:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24751 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 24751@debbugs.gnu.org Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.14839192897096 (code B ref 24751); Sun, 08 Jan 2017 23:49:02 +0000 Received: (at 24751) by debbugs.gnu.org; 8 Jan 2017 23:48:09 +0000 Received: from localhost ([127.0.0.1]:47252 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQNC4-0001qJ-Nv for submit@debbugs.gnu.org; Sun, 08 Jan 2017 18:48:08 -0500 Received: from mail-io0-f180.google.com ([209.85.223.180]:33792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQNC3-0001px-JR; Sun, 08 Jan 2017 18:48:07 -0500 Received: by mail-io0-f180.google.com with SMTP id f103so71814467ioi.1; Sun, 08 Jan 2017 15:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=1KFgcECMpMc1iB8Hn17S22S8qlHFCUILTafu2pb1N54=; b=npFZjG6Gja5aXU5fQL3lkE/UB3wXBHu+EnotSmdNtC3wrZNP6kfMrhd3v1EXvJRoTg cUUEPYCSWHw4rlS6GoxvFHakRGQPA4EtWyPU6yY0hFWc0N3ziFwbL2/rqebsxrKc0Iuj wCjOYvzeSU/pLz3ly4uc1bQwmqggnCfcSWGlg+95PnQvvym+NhlbHobtbb8tVxWXQVVi IZK5mSGT2yoWr1/bN2cleXJENUv4yZe1+OAi9hP5KBFQGp8E+xJFPala3zldV5Wfwkxi Y+9aEH2tZc2Xudz8joi/0HJNrlrL7AFiOZR6Qk4/NmDDj+XCVAa9CPQKWgmci2FVT8d6 /oXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=1KFgcECMpMc1iB8Hn17S22S8qlHFCUILTafu2pb1N54=; b=WtzwWMkoDvGM7PejsZnOSJqPqdfDQojXMARxNsPZ/l6rtXlEWyYw2QbTc1a7Lijnk8 lkPqx6YkVQNj37m5n6JTtFhFVaAuNC1ZmBMc5PNh755UvAK7EsBRcTG0DzwYV+4MpMpW z9xDXhBCAKIuQ5SofPotmnENNUwWaZ8thb8JtTnWHb+XuQxWc4D+esy2oD6gdI8Y+MxV GJn5MHxaoY2KeNL1uh/oULpXX2LHvPC9MqTMMxtk8CqKJOJ+pFCDHy9zbNt5w6RrcbQG FtHDP6M8tvq2VhwFhcDbJ7HEUqjWdeDgYM204KYajoNXbioFwjUkwLX4bl4dtvhyLxgC aJ8A== X-Gm-Message-State: AIkVDXIGgZ5LZT0YoBiFqiCvPEv+CSBL0nI3mF1z8YRN5BlWpoWtGLGVH6avWlwS23HGHw== X-Received: by 10.107.21.2 with SMTP id 2mr67967360iov.179.1483919281940; Sun, 08 Jan 2017 15:48:01 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id h69sm5391842ith.5.2017.01.08.15.48.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 08 Jan 2017 15:48:01 -0800 (PST) From: npostavs@users.sourceforge.net References: <87twc6tl0i.fsf@users.sourceforge.net> <83h97nlknj.fsf@gnu.org> <87mvhdoh4q.fsf@users.sourceforge.net> <83zilcipcr.fsf@gnu.org> <87a8d4lyzo.fsf@users.sourceforge.net> <83a8d3cq9s.fsf@gnu.org> <87wpg5l9st.fsf@users.sourceforge.net> <83d1hwhgdi.fsf@gnu.org> <87r36ckzca.fsf@users.sourceforge.net> <83polvfl3h.fsf@gnu.org> <87oa1fknx9.fsf@users.sourceforge.net> <83y40idqm3.fsf@gnu.org> <877f6e6p79.fsf@users.sourceforge.net> <83r34lfpsl.fsf@gnu.org> <8737h171rx.fsf@users.sourceforge.net> <83inpxferv.fsf@gnu.org> Date: Sun, 08 Jan 2017 18:49:05 -0500 In-Reply-To: <83inpxferv.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 02 Jan 2017 21:22:28 +0200") Message-ID: <87inpp15am.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) tags 24751 fixed close 24751 26.1 quit I've pushed to master. 1: 2017-01-08 18:45:52 -0500 9a19f26cd796c7321f659a8dbea5296b0eeea51d Fix computation of regex stack limit 2: 2017-01-08 18:45:52 -0500 13c6f1d185d301aad2f6d756c148acb2edd0889f Use expanded stack during regex matches