ID:               47376
 User updated by:  pahan at hubbitus dot spb dot su
 Reported By:      pahan at hubbitus dot spb dot su
 Status:           Bogus
 Bug Type:         PCRE related
 Operating System: Linux
 PHP Version:      5.3.0beta1
 New Comment:

>Your pattern could be: /(@@ -[\d,]+ \+[\d,]+ @@\s)(?1)+/
Yes, it seems as workaround (for my current work I apply other
workaraund too). It has not similar stack problems?

Wuote from info by you link:
Unfortunately,  the  effect  of  running out of stack is often
SIGSEGV,
       though sometimes a more explicit error message is given. You 
can  nor-
       mally increase the limit on stack size by code such as this:

         struct rlimit rlim;
         getrlimit(RLIMIT_STACK, &rlim);
         rlim.rlim_cur = 100*1024*1024;
         setrlimit(RLIMIT_STACK, &rlim);

So, main question is - may you correctly handle this problem at all
(throw/catch exceptions, fire errors, warnings etc.)?? 
For example, code such:
echo preg_replace('/(@@ -[\d,]+ \+[\d,]+ @@\s){2,643}/s', '-some
data-', $text);
generate warning:
PHP Warning:  preg_replace(): Compilation failed: regular expression is
too large at offset 33 in /home/pasha/pcre-php-bug/pcre_bug.php on line
14
and all ok - I can correctly handle this situation on my script.

In any case, on production server segmentation fault depended from
incoming data is very-very bad idea.


Previous Comments:
------------------------------------------------------------------------

[2009-02-13 10:10:45] fel...@php.net

It's a known PCRE issue, and is documented:
http://www.manpagez.com/man/3/pcrestack/

------------------------------------------------------------------------

[2009-02-13 10:01:29] fel...@php.net

Your pattern could be: /(@@ -[\d,]+ \+[\d,]+ @@\s)(?1)+/

------------------------------------------------------------------------

[2009-02-13 09:01:51] pahan at hubbitus dot spb dot su

Thank you for the links it was pretty usefully.

I'm read information on it. Very strange read PHP documentation like:
====QUOTE:http://ru.php.net/manual/en/pcre.configuration.php====
pcre.recursion_limit integer 
PCRE's recursion limit. Please note that if you set this value to a
*high number you may consume all the available process stack and
eventually crash PHP* (due to reaching the stack size limit imposed by
the Operating System).
====/QUOTE====
Really you can't provide any runtime check and provide standard way to
handle errors (or warnings)???
So, this low level limitation may be in pcre, but crash of PHP is PHP
BUG in any case!

And, If you a interesting, I'm make more investigation on this theme:
On default OS limit:
$ ulimit -s
10240
example script behaves as:
//ini_set('pcre.recursion_limit', 9939);//Segmentation fault           
                                                       
//ini_set('pcre.recursion_limit', 9938);//Work 

So, If I increase stack size on my system:
$ ulimit -s 65536
all work fine, as expected!!!

------------------------------------------------------------------------

[2009-02-13 00:53:14] fel...@php.net

It isn't a PHP bug.

See bug#33468, bug#39387.

Thanks.

------------------------------------------------------------------------

[2009-02-12 22:51:08] pahan at hubbitus dot spb dot su

Sorry, sorry. Off course line "$text = file();" in reproduce code
unnecessary. Please remove it.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/47376

-- 
Edit this bug report at http://bugs.php.net/?id=47376&edit=1

Reply via email to