|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: php at richardneill dot org
New email:
PHP Version: OS:


 [2011-04-27 18:43 UTC] php at richardneill dot org
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";
	echo "success\n";

Expected result:
preg_replace shouldn't fail.

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


Add a Patch

Pull Requests

Add a Pull Request


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]
-Status: Open +Status: Feedback
 [2011-04-27 21:54 UTC]
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
 - 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 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]
-Package: *Regular Expressions +Package: PCRE related
 [2011-05-21 21:35 UTC]
Not a PHP bug.
 [2011-05-21 21:49 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: rasmus
 [2011-05-21 21:49 UTC]
I have increased the backtrack limit to 1000000 in all branches.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Mon Sep 20 05:03:36 2021 UTC