#33468 [Com]: preg_match on long strings fails
ID: 33468
Comment by: bugs dot php dot net at chsc dot dk
Reported By: mjsherman at chartermi dot net
Status: Assigned
Bug Type: PCRE related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-08-09)
Assigned To: andrei
New Comment:
An even simpler testcase:
$data = str_repeat('a', );
preg_match('/(?:[a])*/', $data, $reg);
Notice that the parenthesis is non-capturing, i.e. we don't even put a
lot of elements in the $reg array.
Previous Comments:
[2005-08-09 10:36:28] [EMAIL PROTECTED]
Happens also with the new PCRE 6.2 lib which was bundled in PHP CVS
today.
[2005-06-24 19:30:06] [EMAIL PROTECTED]
Andrei, could you check it plz.
As far as I understand, this is something not related to PHP, but just
another PCRE limitation.
[2005-06-24 19:21:22] mjsherman at chartermi dot net
Just tested with 5.1.0beta2
Same problem.
[2005-06-24 18:28:01] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-06-24 18:24:34] mjsherman at chartermi dot net
Description:
preg_match, if passed a long subject string, fails unexpectedly.
I have read through the PCRE limitations, and can't see that this is
one of them. I have tried increasing memory limit (to increase the
stack) with the same results.
Cutoff and examples are below:
Reproduce code:
---
$subject = str_repeat('a',100);
$subject .= str_repeat('b', 4370);
$subject .= str_repeat('a', 100);
if (preg_match('/(.*).*?\1/',$subject)) {
echo "OK\n";
}
Expected result:
"OK" to be printed after matching 100 "a"s.
If 4370 is changed to 4369, then "OK" is printed.
Actual result:
--
With 4370 'b's, nothing is printed (failed preg_match)
With 4369 'b's, "OK" is printed (worked).
--
Edit this bug report at http://bugs.php.net/?id=33468&edit=1
#33468 [Com]: preg_match on long strings fails
ID: 33468
Comment by: mstuhu at web dot de
Reported By: mjsherman at chartermi dot net
Status: Assigned
Bug Type: PCRE related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-06-26)
Assigned To: andrei
New Comment:
I'm experiencing the same problem with both preg_match and also
preg_replace_callback.
Though the string I'm having is well down below the limitations of
PCRE, PHP silently skips the function calls.
Sometimes I get a page back, but mostly there's no response from the
Apache server.
My test cases work(ed) fine up to 4.3.10.
After updating to 4.3.11 they're broken.
I've tested 4.3.11 on two different boxes:
the first one runs Red Hat 7 and PCRE Library Version 4.5
the second runs Debian Sarge and PCRE Library Version 5.0
Both show the same problems.
I've also upgraded both boxes to 4.4.0 for testing purposes, but the
problem persists.
When downgrading to 4.3.9 or 4.3.10 the problem disappears on both
boxes.
Judging from the above it seems not to be PCRE related,
I assume there were some code changes
Previous Comments:
[2005-06-24 19:30:06] [EMAIL PROTECTED]
Andrei, could you check it plz.
As far as I understand, this is something not related to PHP, but just
another PCRE limitation.
[2005-06-24 19:21:22] mjsherman at chartermi dot net
Just tested with 5.1.0beta2
Same problem.
[2005-06-24 18:28:01] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-06-24 18:24:34] mjsherman at chartermi dot net
Description:
preg_match, if passed a long subject string, fails unexpectedly.
I have read through the PCRE limitations, and can't see that this is
one of them. I have tried increasing memory limit (to increase the
stack) with the same results.
Cutoff and examples are below:
Reproduce code:
---
$subject = str_repeat('a',100);
$subject .= str_repeat('b', 4370);
$subject .= str_repeat('a', 100);
if (preg_match('/(.*).*?\1/',$subject)) {
echo "OK\n";
}
Expected result:
"OK" to be printed after matching 100 "a"s.
If 4370 is changed to 4369, then "OK" is printed.
Actual result:
--
With 4370 'b's, nothing is printed (failed preg_match)
With 4369 'b's, "OK" is printed (worked).
--
Edit this bug report at http://bugs.php.net/?id=33468&edit=1
