From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") Date: Sun, 01 Jan 2017 22:06:54 +0200 Message-ID: <83tw9ifstd.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1483301297 7948 195.159.176.226 (1 Jan 2017 20:08:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jan 2017 20:08:17 +0000 (UTC) Cc: 24751@debbugs.gnu.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 01 21:08:12 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cNmQN-0001Ku-Im for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Jan 2017 21:08:11 +0100 Original-Received: from localhost ([::1]:54409 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNmQR-0004FO-Mh for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Jan 2017 15:08:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cNmQJ-0004DJ-Gj for bug-gnu-emacs@gnu.org; Sun, 01 Jan 2017 15:08:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cNmQE-0007S6-Ei for bug-gnu-emacs@gnu.org; Sun, 01 Jan 2017 15:08:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51676) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cNmQE-0007S2-BQ for bug-gnu-emacs@gnu.org; Sun, 01 Jan 2017 15:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cNmQE-0007rU-6c for bug-gnu-emacs@gnu.org; Sun, 01 Jan 2017 15:08:02 -0500 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 24751-submit@debbugs.gnu.org id=B24751.148330124030173 (code B ref 24751); Sun, 01 Jan 2017 20:08:02 +0000 Original-Received: (at 24751) by debbugs.gnu.org; 1 Jan 2017 20:07:20 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 In-reply-to: <87inpy7gn2.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:127663 Archived-At: > 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.