octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #51589] crash on regexp


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #51589] crash on regexp
Date: Fri, 28 Jul 2017 13:05:04 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #12, bug #51589 (project octave):

Yeah, it's unfortunate this routine is so fragile.  Should we put a note up
front in the regexp help about this?  Something like


 -- [S, E, TE, M, T, NM, SP] = regexp (STR, PAT)
 -- [...] = regexp (STR, PAT, "OPT1", ...)
     Regular expression string matching.  (See note about stack
     limitations near end of help.)

     Search for PAT in STR and return the positions and substrings of
     any matches, or empty values if there are none.
[snip]

     NOTE: Pattern searches are done with a recursive function
     which can overflow the stack when there are high numbers
     of matches found.  For example:

         regexp (repmat ('a', 1, 1e5), '(a)+');

     Consider constructing pattern searches that reduce the
     number of matches, such as using set complement, then
     further process the return variables with successive
     searches.


A segfault/stack-overflow is such a bad thing because the session history is
lost.  I'm wondering if there is a way we could protect the stack from
overflowing (doesn't sound like).  One thing I've often wondered is if Octave
processing could have a level of protection against this sort of thing,
whether it is seg-faults or cntrl-C whereby it unwinds the stack or "local"
memory.  That is, something like


1) record stack pointer (SP), clear working variable memory space
2) parse code and run
3) if fault or cntrl-C signal, rewind stack pointer (to SP), toss working
memory
4) no error, move working variable memory to global variable memory


Big change of course, a bit OS-like, but perhaps more graceful.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51589>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]