|  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
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
40 - 35 = ?
Subscribe to this entry?

 [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 04:03:36 2021 UTC