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

go to bug id or search bugs for

Bug #42424 PHP5/PCRE fails to match long strings when ungreedy
Submitted: 2007-08-25 13:16 UTC Modified: 2007-08-27 11:17 UTC
From: adam-phpbugs at adam dot gs Assigned:
Status: Not a bug Package: PCRE related
PHP Version: 5.2.3 OS: Any
Private report: No CVE-ID: None
View Add Comment Developer Edit
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.
Password:
Status:
Package:
Bug Type:
Summary:
From: adam-phpbugs at adam dot gs
New email:
PHP Version: OS:

 

 [2007-08-25 13:16 UTC] adam-phpbugs at adam dot gs 
Description:
------------
PHP5/PCRE will fail to match on long strings when UNGREEDY, the boundary 
is around 100k of data.

FWIW, same results if you change x* to x+ down there.

Reproduce code:
---------------
<?php
$data=sprintf("<span>%s</span>",str_repeat("x",99996));
var_dump(preg_match("#<span>(x*?)</span>#",$data));

$data=sprintf("<span>%s</span>",str_repeat("x",99997));
var_dump(preg_match("#<span>(x*?)</span>#",$data));

$data=sprintf("<span>%s</span>",str_repeat("x",99997));
var_dump(preg_match("#<span>(x*)</span>#U",$data));

$data=sprintf("<span>%s</span>",str_repeat("x",99997));
var_dump(preg_match("#<span>(x*)</span>#",$data));
?>

Expected result:
----------------
all 4 expressions should match, this is what occurs with PHP 4.4.7.




Actual result:
--------------
under PHP 5.2.3:
only the first and 4th expression match
under PHP 4.4.7:
all 4 match.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-08-27 11:17 UTC] jani@php.net 
In PHP 5.2.0 two new PCRE ini options were added to prevent possible stack overflows and crashes. One of them is pcre.backtrack_limit.
When you set it high enough your script works as it did earlier (where no such limits existed!)

$ php -dpcre.backtrack_limit=100001 t.php
int(1)
int(1)
int(1)
int(1)
 [2011-01-14 17:12 UTC] php at richardneill dot org 
This isn't bogus; it should at the very least raise an error E_NOTICE.

I've just spent 7 hours tracking down a problem caused by this bug.
and generating you a helpful report:
  http://www.richardneill.org/tmp/preg-error2.txt

I do understand the rationale for the limits (though personally, I think they are 3 orders of magnitude too small, and I'd much rather my script segfaulted rather than silently introducing subtle processing errors to my data).

Could we at least make sure that with display_errors (E_ALL) we get some kind of notification? At minimum, a notice would do, though ideally, this should be a fatal error.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 26 12:01:30 2024 UTC