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

go to bug id or search bugs for

Bug #36553 Apache crashes when using unicode matches for whitespace and control characters
Submitted: 2006-02-27 23:38 UTC Modified: 2006-03-02 20:56 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: php at kaiundina dot de Assigned:
Status: Not a bug Package: PCRE related
PHP Version: 5.1.2 OS: different
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: php at kaiundina dot de
New email:
PHP Version: OS:

 

 [2006-02-27 23:38 UTC] php at kaiundina dot de 
Description:
------------
The statement in the reproduce code simply crashes my server (Win XP Pro, Apache 2, PHP 5.1.0, default-charset UTF 8) and that of my webhoster (Linux, Apache 2, PHP 5.1.2, default-charset Latin1) - time_limit, which is set to 30 s seems not to work.

Executing the script via CLI produces the same result (but can be cancelled by Ctrl-C)

The snipped shall look for adjacent blocks, each persisting of  a separator character followed by one or more characters that aren't control- or separator-characters.

Crashing is independent of the $aName-value and the result, the match would produce.

The example is stripped down from a bigger pattern - always having to kill the webserver after each test is quite annoying :(

Reproduce code:
---------------
<?php

$aName = 'My Name';
preg_match('/^(\\p{Z}[^\\p{C}\\p{Z}]+)*$/', $aName);

?>


Expected result:
----------------
just nothing happens - the function returns and drops its result (false in this case, but doesn't matter)

Actual result:
--------------
Server "crashes": CPU usage is at 100% and Apache doesn't respond to a restart (php compiled as module).

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-02-28 10:34 UTC] tony2001@php.net 
Please report this issue to PCRE library author.
You can also try to compile PHP against external PCRE lib (grab the latest version from pcre.org), the issue may have been already fixed there.
 [2006-02-28 22:07 UTC] php at kaiundina dot de 
Why do you offer a category "PCRE related" when you simply redirect those issues to other responsibilities?

I suggest to drop this category, add a note (like "Issue will be bogussed since we're not responsible") or redirect those issues directly to the guys that handles them.

We're managing huge php-projects and php is getting quite uneconomical - each time we try out some new features there are new oddities arising. The reliability is quite bad.

------
pcre.org is down for the moment :(
 [2006-03-01 08:29 UTC] tony2001@php.net 
There could be problems related to the functions wrapping PCRE lib. But if the problem is related to PCRE lib itself, there is not much we can do about it.

>The reliability is quite bad.
We're waiting for your patches.
 [2006-03-02 20:56 UTC] php at kaiundina dot de 
Not a php issue - thanks anyway for the quick response.

PCRE runs into an infinite loop rather than returning an error/warning.

Unicode patterns should be used along with the PCRE_UTF8 option (my fault).

Looks and works like follows (note the additional 'u' as pattern option):

<?php

$aName = 'My Name';
preg_match('/^(\\p{Z}[^\\p{C}\\p{Z}]+)*$/u', $aName);

?>
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun May 11 15:01:27 2025 UTC