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

go to bug id or search bugs for

Bug #32029 PCRE bugs under Windows XP
Submitted: 2005-02-19 20:42 UTC Modified: 2005-06-07 01:00 UTC
Votes:3
Avg. Score:4.7 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:2 (100.0%)
From: craig at unclecraig dot com Assigned:
Status: No Feedback Package: PCRE related
PHP Version: 5CVS, 4CVS (2005-02-19) OS: win32 only
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: craig at unclecraig dot com
New email:
PHP Version: OS:

 

 [2005-02-19 20:42 UTC] craig at unclecraig dot com 
Description:
------------
I'm using the latest snap shot (php4-win32-STABLE-200502191330) on Win XP with Apache 2.

I've experienced a number of problems with pgrep_replace/pgrep_match that only occur under windows.  The same code works fine under linux.

The example below is easily reproduced.  The expression splits a file into it's components - path, name, ext (where ext can be multi part)

When the name part exceeds 12 chars, the expression no longer matches.  This is not the case using RegExp Coach on the same platform.

I also get a problem when using the following:
// Remove C comments
$content = preg_replace( "|\/\*((?!\*\/).)*\*\/|is", "", $content);

This used to work fine, then suddenly it stopped, no error is returned execution just halts here and the document returns no data.  I made no modification to the PHP base, just some of the files that were being parsed got a bit bigger so this code be a memory issue??? Still no errors are generated php just halts.  (This is one reason I increased the memory_limit directive in the php.ini file)

Please help, as I can no longer debug under windows, and I face having to rewrite large chunks of code to avoid using preg functionality!

-- PHP.INI --
max_execution_time = 150
memory_limit = 64M
extension=php_filepro.dll
extension=php_mcrypt.dll
extension=php_mhash.dll
extension=php_mime_magic.dll
extension=php_zip.dll
[Debugger]
debugger.enabled=on
debugger.profiler_enabled=on
debugger.JIT_enabled=on
debugger.JIT_host = clienthost
debugger.JIT_port = 7869
mime_magic.magicfile = "C:\Program Files\Apache Group\Apache2\conf\magic"

Reproduce code:
---------------
<?php
echo "\n".preg_match('|^((?:(?:\/?[^\/]*)*)(?:\/))?([^\/\.]+)\.([^\/]+)$|i','012345678901.mod.inc',$parts);
echo "\n".preg_match('|^((?:(?:\/?[^\/]*)*)(?:\/))?([^\/\.]+)\.([^\/]+)$|i','0123456789012.mod.inc',$parts);
?>


Expected result:
----------------
1
1

Actual result:
--------------
1
0

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-02-20 19:58 UTC] craig at unclecraig dot com 
Please note I am aware of and use the 'basename' and 'dirname' functions.  The above is just a reproduceable example to demonstrate the the PCRE code is unreliable on Win XP, at least for me.
 [2005-02-21 18:59 UTC] craig at unclecraig dot com 
Replacing '|\/\*((?!\*\/).)*\*\/|is' with '|\/\*.*?\*\/|is' is more efficient preventing greedy matching rather than using look ahead.  Nonetheless, the original reg-ex is still techinically valid and works under linux, so it's still technically a bug.  At a guess there is a memory issue when using look-ahead (and possible look-behind) in PCRE under windows.
 [2005-02-21 19:05 UTC] tony2001@php.net 
It works in the same way for me under Linux, so I think it's probably PCRE problem and PHP has nothing to do with it.
 [2005-02-21 19:21 UTC] craig at unclecraig dot com 
I'm developing on a Windows box for submission on a linux server so I run the same code on both windows and linux, and can assure you that for me both examples given run without problems on Linux.  I can accept this is a PCRE bug/problem however, as the PCRE libraries are obviously different on both platforms.  But running RegExp Coach on the same platform caused no problems with the same input and expression.  This suggests that it may be an interaction between PHP and the PCRE code - perhaps in the way it allocates memory (look-aheads are quite memory intensive I believe).

Nonetheless, if it is a PCRE bug, is there any way for PHP to raise an error, rather than terminating without warning.  It took a long time to track the bug down by stepping through code until the correct line was isolated, as PCRE is implemented as a built-in function, it shouldn't cause the runtime to terminate unexpectedly (ie crash).

The nature of any test is to implement controls and limit the variables, as you can see from above, I have demonstrated satisfactorily that the regular expression works without issue on multiple platforms with the same input, except when running with PHP under windows, i.e.

PHP, linux -> Pass
RegEx Coach, Windows -> Pass
PHP, Windows -> Fail

This demonstrates that the PCRE code works successfully except under the one condition where the variable was PHP.  It is unlikely therefore that there is no issue with the way PHP uses the PCRE code, hence the bug report was filed here.

Thank you
 [2005-05-30 16:34 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
 [2005-06-07 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Oct 12 06:01:27 2024 UTC