FAQ

[zefram@fysh.org - Wed Oct 20 13:36:58 2004]:

Robert via RT wrote:
This sounds like the the well known regex recursion & stack issue.
I've seen the stack overflow due to backtracking records, in several
circumstances. This problem with the long string doesn't look like that.
Note that the extremely long string is required even though the regexp
execution can't possibly get past the first few characters, and that the
code in unexecuted parts of the regexp affects the result. Neither of
these features resembles the stack overflow problems that I've seen.
Also, as I pointed out, it's not affected by stack size.
Based on the fact that this regexp is still core dumping, another issue
is involved here. I'd include the backtrace, but

"/home/steve/smoke/perl-current/core" is not a core dump: File format
not recognize

Hmmm...Hate!

Search Discussions

  • Dave Mitchell at May 20, 2006 at 12:49 am

    On Wed, Mar 29, 2006 at 09:48:41AM -0800, Steve Peters via RT wrote:
    [zefram@fysh.org - Wed Oct 20 13:36:58 2004]:

    Robert via RT wrote:
    This sounds like the the well known regex recursion & stack issue.
    I've seen the stack overflow due to backtracking records, in several
    circumstances. This problem with the long string doesn't look like that.
    Note that the extremely long string is required even though the regexp
    execution can't possibly get past the first few characters, and that the
    code in unexecuted parts of the regexp affects the result. Neither of
    these features resembles the stack overflow problems that I've seen.
    Also, as I pointed out, it's not affected by stack size.
    Based on the fact that this regexp is still core dumping, another issue
    is involved here. I'd include the backtrace, but

    "/home/steve/smoke/perl-current/core" is not a core dump: File format
    not recognize
    The super-linear cache thinggy seeds PL_reg_maxiter with the value
    (length of string) * (index number of this CURLYX).

    For length=170E6 and index=13, this causes wrap-round to a negative
    value, which means the code assumes the cache has already been allocated,
    and SEGV hilarity ensues. Fixed by the change below.

    --
    The warp engines start playing up a bit, but seem to sort themselves out
    after a while without any intervention from boy genius Wesley Crusher.
    -- Things That Never Happen in "Star Trek" #17


    Change 28248 by davem@davem-splatty on 2006/05/20 00:43:42

    [perl #32041] SEGV with complicated regexp and long string
    PL_reg_maxiter was wrapping to a negative value

    Affected files ...

    ... //depot/perl/op.c#823 edit
    ... //depot/perl/regexec.c#423 edit

    Differences ...

    ==== //depot/perl/op.c#823 (text) ====


    ==== //depot/perl/regexec.c#423 (text) ====

    @@ -3652,6 +3652,9 @@
    *that* much linear. */
    if (!PL_reg_maxiter) {
    PL_reg_maxiter = (PL_regeol - PL_bostr + 1) * (scan->flags>>4);
    + /* possible overflow for long strings and many CURLYX's */
    + if (PL_reg_maxiter < 0)
    + PL_reg_maxiter = I32_MAX;
    PL_reg_leftiter = PL_reg_maxiter;
    }
    if (PL_reg_leftiter-- == 0) {

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedMar 29, '06 at 5:48p
activeMay 20, '06 at 12:49a
posts2
users2
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase