php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #61744 preg_match crashes
Submitted: 2012-04-16 10:57 UTC Modified: 2012-04-17 09:37 UTC
From: bugzilla33 at gmail dot com Assigned:
Status: Not a bug Package: *Regular Expressions
PHP Version: 5.4.1RC2 OS: Win 7 64-bit
Private report: No CVE-ID: None
 [2012-04-16 10:57 UTC] bugzilla33 at gmail dot com
Description:
------------
preg_match crashes

Test script:
---------------
<?=preg_match('#^(A{1,2}B)+$#',str_repeat('AB',300));?>

Expected result:
----------------
preg_match no crash

Actual result:
--------------
preg_match crashes

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-04-16 11:01 UTC] bugzilla33 at gmail dot com
Try as Apache module.
php.exe testcase.php does not crash
 [2012-04-16 14:52 UTC] laruence@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I think it is probable because of : 
http://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit
 [2012-04-16 14:52 UTC] laruence@php.net
-Status: Open +Status: Feedback
 [2012-04-16 16:13 UTC] bugzilla33 at gmail dot com
I checked recursion-limit:
pcre.backtrack_limit 1000000
pcre.recursion_limit 100000

On fastCGI or direct php.exe testcase.php does not crash.

When use Apache 2.2.21 with php module with the same php.ini
testcase.php crash apache.

Now I am at home. The same crash like at work - two other machines.
 [2012-04-16 16:13 UTC] bugzilla33 at gmail dot com
-Status: Feedback +Status: Open
 [2012-04-16 16:18 UTC] rasmus@php.net
Windows-only, I assume? Apache uses PCRE as well, so perhaps Apache on Windows is 
resetting the PCRE limits? I assume it doesn't crash if you reduce the 300 there 
to something smaller?
 [2012-04-16 16:29 UTC] bugzilla33 at gmail dot com
str_repeat('AB',200) do not crash

str_repeat('AB',300) crashes - browser freeze about 4sec and info - browser can not display site
 [2012-04-16 16:31 UTC] bugzilla33 at gmail dot com
...but using apache module phpinfo also says:
pcre.backtrack_limit 1000000
pcre.recursion_limit 100000
 [2012-04-16 16:34 UTC] bugzilla33 at gmail dot com
...and I tested Windows 7 only (32-bit and 64-bit)
 [2012-04-16 16:37 UTC] bugzilla33 at gmail dot com
When use #^(A{1}B)+$# instead of #^(A{1,2}B)+$#
testcase returns 1 - no crash
 [2012-04-16 16:53 UTC] bugzilla33 at gmail dot com
Tested also on Apache 2.4.2 + php_module (from www.apachelounge.com) + PHP 5.4.0 VC9 Thread Safe

Test script still crashes.
 [2012-04-16 17:12 UTC] rasmus@php.net
Are you using mod_security in your Apache?
 [2012-04-16 17:23 UTC] bugzilla33 at gmail dot com
No, I have original httpd.conf from package
and original php.ini-development -> php.ini
 [2012-04-16 17:36 UTC] pajoye@php.net
-Status: Open +Status: Not a bug
 [2012-04-16 17:36 UTC] pajoye@php.net
Increase the stack, either using the http configuration or using the editbin.exe 
utility.

The stack is overridden by the executable running php, in case of mod_php it is 
apache's.
 [2012-04-16 20:20 UTC] bugzilla33 at gmail dot com
I think that this is not the fault of the stack.
In PHP 5.3 this problem does not occur.
 [2012-04-17 08:58 UTC] pajoye@php.net
Different pcre version or code, the situation where a crash occurs may differ. 
However all the symptoms of a stack related crash are present. Increase it and you 
should be good.
 [2012-04-17 09:37 UTC] bugzilla33 at gmail dot com
I increased by editbin to 8mb and it works!

Why apache is compiling with 256kb stack?
Is stack increasing dangerous?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 12:01:31 2024 UTC