From @rspier

This is a meta-bug. It's purpose is to be linked to/from other
tickets of the same type for tracking purposes. (Via "DependsOn")

This ticket is for bugs related to the overflow of the OS stack during
recursion in the perl regex engine.

Generally they can be "worked around" by increasing the stack size by
using ulimit (bash/sh/ksh/zsh) or limit (csh/tcsh).

The long term plan is to rewrite the regex engine to not use the stack
for recursion.

From @smpeters

[rspier@​pobox.com - Wed Oct 22 21​:35​:51 2003]​:

This is a meta-bug. It's purpose is to be linked to/from other
tickets of the same type for tracking purposes. (Via "DependsOn")

This ticket is for bugs related to the overflow of the OS stack during
recursion in the perl regex engine.

Generally they can be "worked around" by increasing the stack size by
using ulimit (bash/sh/ksh/zsh) or limit (csh/tcsh).

The long term plan is to rewrite the regex engine to not use the stack
for recursion.

All other tickets depending on this ticket have been resolved.

The RT System itself - Status changed from 'new' to 'open'

@smpeters - Status changed from 'open' to 'resolved'

From @hvds

"Steve Peters via RT" <perlbug-followup@​perl.org> wrote​:
:All other tickets depending on this ticket have been resolved.

Cool, but expect to find many more that weren't linked to the metabug.

Hugo

From @smpeters

On Wed, Mar 29, 2006 at 11​:56​:35AM +0100, hv@​crypt.org wrote​:

"Steve Peters via RT" <perlbug-followup@​perl.org> wrote​:
:All other tickets depending on this ticket have been resolved.

Cool, but expect to find many more that weren't linked to the metabug.

Yes, I'm looking into the additional tickets related to this problem. The
nice thing to notice, so far, is that there seems to have been an
unintended optimization. I haven't benchmarked anything before or after
the change, but it certainly seems that blowing the stack was quite time
consuming :)

Steve Peters
steve@​fisharerojo.org