all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: npostavs@users.sourceforge.net
To: Eli Zaretskii <eliz@gnu.org>
Cc: 24751@debbugs.gnu.org
Subject: bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size")
Date: Wed, 16 Nov 2016 18:25:22 -0500	[thread overview]
Message-ID: <87oa1fknx9.fsf@users.sourceforge.net> (raw)
In-Reply-To: <83polvfl3h.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 16 Nov 2016 18:25:22 +0200")

Eli Zaretskii <eliz@gnu.org> 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.  */






  reply	other threads:[~2016-11-16 23:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21  3:54 bug#24751: 26.0.50; Regex stack overflow not detected properly (gets "Variable binding depth exceeds max-specpdl-size") npostavs
2016-11-04  8:22 ` Eli Zaretskii
2016-11-05 19:34   ` npostavs
2016-11-06 15:45     ` Eli Zaretskii
2016-11-13  5:39       ` npostavs
2016-11-13 16:12         ` Eli Zaretskii
2016-11-15  3:08           ` npostavs
2016-11-15 16:12             ` Eli Zaretskii
2016-11-16  1:06               ` npostavs
2016-11-16 16:25                 ` Eli Zaretskii
2016-11-16 23:25                   ` npostavs [this message]
2016-11-17 16:21                     ` Eli Zaretskii
2016-11-19 10:02                       ` Eli Zaretskii
2017-01-01 18:33                       ` npostavs
2017-01-01 18:41                         ` Eli Zaretskii
2017-01-01 18:57                           ` npostavs
2017-01-01 20:06                             ` Eli Zaretskii
2017-01-02  4:49                       ` npostavs
2017-01-02 15:24                         ` Eli Zaretskii
2017-01-02 18:30                           ` npostavs
2017-01-02 19:22                             ` Eli Zaretskii
2017-01-08 23:49                               ` npostavs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87oa1fknx9.fsf@users.sourceforge.net \
    --to=npostavs@users.sourceforge.net \
    --cc=24751@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.