php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #54614 Trivial RE failure: /([^b]*a*)*$/
Submitted: 2011-04-27 18:43 UTC Modified: 2011-05-21 21:49 UTC
From: php at richardneill dot org Assigned: rasmus (profile)
Status: Closed Package: PCRE related
PHP Version: 5.3.6 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: php at richardneill dot org
New email:
PHP Version: OS:

 

 [2011-04-27 18:43 UTC] php at richardneill dot org 
Description:
------------
If I search in the string :   'aaaaaaaab'
with the RE:   '/([^b]*a*)*$/'

then preg_replace fails with a backtrack-limit error. (error 2)
I have backtrack.limit configured to 32MB, so something is very wrong.

The example fails on several different PHP versions, CPU architectures and Linux
Distros.  However, using Perl for the same RE works fine.

Test script:
---------------
$contents =  "aaaaaaaab";
$search = '/([^b]*a*)*$/';
$result = preg_replace($search,"x",$contents);
if ($result === NULL){
	echo "preg failed, error is ".preg_last_error()."\n";
}else{
	echo "success\n";
}

Expected result:
----------------
preg_replace shouldn't fail.

Actual result:
--------------
preg_replace returns NULL, and preg_last_error returns 2.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-04-27 21:15 UTC] php at richardneill dot org 
A slightly simpler test case is:
  $contents =  "aaaaaaaab";
  $search = '/(a*a*)*$/';
 [2011-04-27 21:54 UTC] rasmus@php.net
-Status: Open +Status: Feedback
 [2011-04-27 21:54 UTC] rasmus@php.net 
With pcre.backtrack_limit = 1000000 this works fine for me on 5.3.6. Are you sure 
you increased the limit in the right place?
 [2011-04-27 23:47 UTC] php at richardneill dot org
-Status: Feedback +Status: Open
 [2011-04-27 23:47 UTC] php at richardneill dot org 
Sorry, my bad (sort of). 

There is a genuine bug that affected longer regexps even with backtrack.limit set
to 32M, which I saw on 5.3.2, but is now solved on 5.3.6.

Unfortunately, the test-case which I simplified for the bug-report didn't
remember to set backtrack.limit (I thought I'd done it in php.ini, but had
actually done it explicitly with ini.set in my original script). So the test
case:
 - works for backtrack.limit = 1M  (on both 5.3.2 and 5.3.6)
 - fails for the default 100k   on both. 

Either way, it's still something that, imho, should work on a default install.

May I make a few suggestions:

 * backtrack.limit should be raised by default, to at least 10M.
 * backtrack.limit should default to 100M for the CLI version of PHP.
 
 * validating bug reports is painful, partly because I had to spend some extra
time tracking down the latest version of PHP and building it. This is error-
prone. How about providing a sandboxed VM on bugs.php.net where we can paste our
own code to check it? This would make it far easier to file correct bug reports.
(it would take the reporter 3 minutes, rather than an hour).
 [2011-05-21 21:35 UTC] felipe@php.net
-Package: *Regular Expressions +Package: PCRE related
 [2011-05-21 21:35 UTC] felipe@php.net 
Not a PHP bug.
 [2011-05-21 21:49 UTC] rasmus@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: rasmus
 [2011-05-21 21:49 UTC] rasmus@php.net 
I have increased the backtrack limit to 1000000 in all branches.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Jun 30 22:01:34 2025 UTC