#28072 [NEW]: static array with some constant keys will be incorrectly ordered
From: pages at inrp dot fr Operating system: Fedora 2 test 2 PHP version: 4.3.6 PHP Bug Type: Scripting Engine problem Bug description: static array with some constant keys will be incorrectly ordered Description: Initialising a static associative array using constants as keys will give an incorrectly ordered array. Apparently, elements with constant keys will always appear AFTER elements without constant keys. Reproduce code: --- "111", "b" => "222", THIRD_KEY => "333", "d" => "444" ); print_r($arr); } test(); ?> Expected result: Array ( [a] => 111 [b] => 222 [c] => 333 [d] => 444 ) Actual result: -- Array ( [b] => 222 [d] => 444 [a] => 111 [c] => 333 ) -- Edit bug report at http://bugs.php.net/?id=28072&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28072&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28072&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28072&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28072&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28072&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28072&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28072&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28072&r=support Expected behavior: http://bugs.php.net/fix.php?id=28072&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28072&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28072&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28072&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28072&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28072&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28072&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28072&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28072&r=float
#27070 [Bgs]: preg_match() crashes Apache on VERY SIMPLE pattern but large subject size
ID: 27070 User updated by: pages at inrp dot fr Reported By: pages at inrp dot fr Status: Bogus Bug Type: Reproducible crash Operating System: Fedora Core 1 (Linux) PHP Version: 5.0.0b3 (beta3) New Comment: I agree every function has its own limitations. And if you know them, then you can do some checkings on the values of the parameters you want to pass to the function BEFORE to call it. So let's see what http://www.pcre.org/pcre.txt says about the PCRE library limitations : 1. "The maximum length of a compiled pattern is 65539". The length of my pattern is 4. I suppose the "compiled pattern" will be OK. (But what is exactly a "compiled pattern" ? And how can I know in advance the length it will have ?) 2. "All values in repeating quantifiers must be less than 65536". I don't use any repeating quantifiers. OK. 3. "The maximum number of capturing subpatterns is 65535". I have only one. OK. 4. "The maximum depth of nesting parenthesized subpattern is 200". Here the depth is 1. OK. 5. "The maximum length of a subject string is the largest positive number that an integer variable can hold". My subject has a length of 13800 so it's OK. 6. "However, PCRE uses recursion to handle subpatterns and indefinite repetition. This means that the available stack space may limit the size of a subject string that can be processed by certain patterns." So this could be the reason why I get a segmentation fault? That's why I tried to set memory_limit to 64M in php.ini so my script should have enough available stack space. But it still crashes ! (with the same subject size i.e. 13800) Anyway, shouldn't we get something like : Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 13801 bytes) in crashme.php on line 5 instead of a seg fault + crash ? Previous Comments: [2004-01-29 00:29:12] [EMAIL PROTECTED] This is PCRE limitation. See also: http://www.pcre.org/pcre.txt [2004-01-28 07:58:41] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. ---- [2004-01-28 06:16:59] pages at inrp dot fr Description: After running the script bellow, /var/log/httpd/error_log says: [Wed Jan 28 00:19:30 2004] [notice] child pid 13744 exit signal Segmentation fault (11) It has been tested on 3 different system : - Red Hat 8.0 + Apache 2.0.40 + PHP 4.2.2 - Red Hat 9 + Apache 2.0.40 + PHP 4.2.2 - Fedora Core 1 + Apache 2.0.48 + 5.0.0b3 Some statistics : - with pattern "/(a)*/", it crashes with a subject length > 13800 - with pattern "/((a))*/", it crashes with a subject length > 9200 - with pattern "/(((a)))*/", it crashes with a subject length > 6900 - with pattern "/a*/", it crashes with a subject length > 5600 - with pattern "/(a)*/", it crashes with a subject length > 4600 - with pattern "/((a))*/", it crashes with a subject length > 4000 - etc... Reproduce code: --- Expected result: No crash Actual result: -- Crash :-( -- Edit this bug report at http://bugs.php.net/?id=27070&edit=1
#27070 [NEW]: preg_match() crashes Apache on VERY SIMPLE pattern but large subject size
From: pages at inrp dot fr Operating system: Fedora Core 1 (Linux) PHP version: 5.0.0b3 (beta3) PHP Bug Type: Reproducible crash Bug description: preg_match() crashes Apache on VERY SIMPLE pattern but large subject size Description: After running the script bellow, /var/log/httpd/error_log says: [Wed Jan 28 00:19:30 2004] [notice] child pid 13744 exit signal Segmentation fault (11) It has been tested on 3 different system : - Red Hat 8.0 + Apache 2.0.40 + PHP 4.2.2 - Red Hat 9 + Apache 2.0.40 + PHP 4.2.2 - Fedora Core 1 + Apache 2.0.48 + 5.0.0b3 Some statistics : - with pattern "/(a)*/", it crashes with a subject length > 13800 - with pattern "/((a))*/", it crashes with a subject length > 9200 - with pattern "/(((a)))*/", it crashes with a subject length > 6900 - with pattern "/a*/", it crashes with a subject length > 5600 - with pattern "/(a)*/", it crashes with a subject length > 4600 - with pattern "/((a))*/", it crashes with a subject length > 4000 - etc... Reproduce code: --- Expected result: No crash Actual result: -- Crash :-( -- Edit bug report at http://bugs.php.net/?id=27070&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27070&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27070&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27070&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27070&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27070&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27070&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27070&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27070&r=support Expected behavior: http://bugs.php.net/fix.php?id=27070&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27070&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27070&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27070&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27070&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27070&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27070&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27070&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27070&r=float
