ID:               32029
 Updated by:       [EMAIL PROTECTED]
 Reported By:      craig at unclecraig dot com
-Status:           Open
+Status:           Feedback
 Bug Type:         PCRE related
 Operating System: win32 only
 PHP Version:      5CVS, 4CVS (2005-02-19)
 New Comment:

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




Previous Comments:
------------------------------------------------------------------------

[2005-02-21 19:21:19] 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-02-21 19:05:41] [EMAIL PROTECTED]

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 18:59:41] 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-20 19:58:49] 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-19 20:42:18] 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


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=32029&edit=1

Reply via email to