#41977 [NEW]: A feature to detect post_max_size exceeded (plus friends)
From: mikko dot rantalainen at peda dot net Operating system: Ubuntu Linux 6.06 PHP version: 5CVS-2007-07-12 (CVS) PHP Bug Type: Feature/Change Request Bug description: A feature to detect post_max_size exceeded (plus friends) Description: As described in http://php.net/manual/en/ini.core.php#ini.post-max-size if the POST data is greater than post_max_size, then both $_POST and $_FILES are empty. The documentation shows a way using the $_GET array as a workaround to detect the situation. However, such workaround cannot be always used because script author may not be the author of the original form and as such cannot add any GET parameters to said form. A method to identify the situation where the user has exceeded post_max_size is therefore required. I'm suggesting a generic solution: Add function get_server_status() This function returns an integer which is a sum (bit mask) of following constants /** HTTP input has or had GET parameters */ SERVER_STATUS_HAD_GET_DATA 1 /** HTTP input has or had POST data */ SERVER_STATUS_HAD_POST_DATA 2 /** HTTP input has or had uploaded files */ SERVER_STATUS_HAD_FILES 4 /** post_max_size was exceeded, $_POST and $_FILES are empty */ SERVER_STATUS_POST_MAX_SIZE_TRIGGERED 8 /** max_filesize was exceeded */ SERVER_STATUS_UPLOAD_MAX_FILESIZE_TRIGGERED 16 /** memory_limit was exceeded before start of the script */ SERVER_STATUS_MEMORY_LIMIT_TRIGGERED 32 /** max_input_time exceeded before start of the script */ SERVER_STATUS_MAX_INPUT_TIME_TRIGGERED 64 This way a script could also handle the case there memory_limit was hit because the uploaded file was too big (at least older versions of PHP required at least as much memory as the size of the upload). However, because the memory space that was not enough for file upload is now free to use for PHP, the script should be able to handle the situation using that same memory (e.g. tell the user about the issue in a nice way or redirect to alternative method). Note that I've named the function get_server_status() instead of get_input_status() or get_http_input_status() so that this same function can be extended in the future for other server/php host status. Feel free to drop constants/situations that cannot be handled by the script, they are of no use in any case. -- Edit bug report at http://bugs.php.net/?id=41977&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41977&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41977&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41977&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41977&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41977&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41977&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41977&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41977&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41977&r=support Expected behavior:http://bugs.php.net/fix.php?id=41977&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41977&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41977&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41977&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41977&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41977&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41977&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41977&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41977&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41977&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41977&r=mysqlcfg
#33151 [NEW]: [RFE] Implement a sane behavior when PCRE runs out of stack space
From: mikko dot rantalainen at peda dot net Operating system: Linux PHP version: 5.0.4 PHP Bug Type: PCRE related Bug description: [RFE] Implement a sane behavior when PCRE runs out of stack space Description: PHP already has a number of bugs reported (http://bugs.php.net/search.php?search_for=crash+segmentation&boolean=0&limit=30&order_by=&direction=ASC&cmd=display&status=All&bug_type%5B%5D=PCRE+related) because of PCRE related crashes that are result of PCRE using heavy recursion with some patterns. Making always sure that both pattern and input string are always safe when using functions implemented with PCRE is really hard from PHP code because the most often hit limit is too small stack and PCRE is really the only part of the code that has knowledge to compute the stack usage. PHP already has it's own copy of PCRE and I'm requesting that that copy is modified so that PCRE is aware of stack usage and returns an error if computing the result would result in stack overflow and possible segmentation fault. If that is considered to be too much of work, PHP should at least put a hard limit on recursion as described in PCRE documentation: http://www.pcre.org/pcre.txt: "LIMITING PCRE RESOURCE USAGE ...a limit can be placed on the resources used by a single call to pcre_exec(). The limit can be changed at run time, as described in the pcreapi documentation..." Another way to workaround this problem is described by jorton at php.net in bug #28461: "One way PHP could mitigate the issue is to to set the match_limit field in the pcre_extra structure which puts a limit on the depth of the stack recursion." (I'm not sure if this is the actual implementation of above note?) Rationale: preg_* functions are often used for input validation just like in Perl. However, it cannot be safely used for that purpose because of all these bugs that result in stack overflows and/or segmentation faults. Increasing stack size cannot be as a workaround because stack usage seems to be exponential. (Resulting segmentation faults inside an Apache module are real pain in the ass to debug, too.) Reproduce code: --- Expected result: preg_match() should return true because the test string passes the test that it's composed of a's possibly followed by b's. Actual result: -- Crash. Isn't limited to PHP 5.x. I wouldn't expect 100KB of text to be too much because I've set my stack to 8192KB (more than 80x the size of the string to search) but I still get segmentation fault. Increase the counter "10" to reproduce the crash if you have huge stack. -- Edit bug report at http://bugs.php.net/?id=33151&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33151&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33151&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33151&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33151&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33151&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33151&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33151&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33151&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33151&r=support Expected behavior: http://bugs.php.net/fix.php?id=33151&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33151&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33151&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33151&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33151&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33151&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33151&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33151&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33151&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33151&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33151&r=mysqlcfg
#30798 [Bgs->Csd]: debug_backtrace returns invalid data in some cases
ID: 30798
User updated by: mikko dot rantalainen at peda dot net
Reported By: mikko dot rantalainen at peda dot net
-Status: Bogus
+Status: Closed
Bug Type: Reproducible crash
Operating System: Mandrake Linux 10.0
-PHP Version: Irrelevant
+PHP Version: 4.3.9
New Comment:
I just checked this problem again. The reproduce code segfaults 4.3.9
but works with 4.3.10. Marking as closed.
Previous Comments:
[2004-11-15 18:40:47] [EMAIL PROTECTED]
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
.
[2004-11-15 18:31:29] mikko dot rantalainen at peda dot net
Description:
Attached script crashes PHP 4.3.4 (plus security fixes) which is latest
versions distributed with Mandrake Linux.
Reproduce code:
---
Check log.");
set_error_handler("__errorHandler");
$parts = split("/",array()); # generate error here
print("EOF.");
?>
Expected result:
A warning message have been sent to server log and a full page should
have been returned to a client.
Actual result:
--
PHP crashes at line marked with "XXX". The problem seems to be related
to the fact that the error is generated with incorrect call to
split().
--
Edit this bug report at http://bugs.php.net/?id=30798&edit=1
#30798 [NEW]: debug_backtrace returns invalid data in some cases
From: mikko dot rantalainen at peda dot net
Operating system: Mandrake Linux 10.0
PHP version: Irrelevant
PHP Bug Type: Reproducible crash
Bug description: debug_backtrace returns invalid data in some cases
Description:
Attached script crashes PHP 4.3.4 (plus security fixes) which is latest
versions distributed with Mandrake Linux.
Reproduce code:
---
Check log.");
set_error_handler("__errorHandler");
$parts = split("/",array()); # generate error here
print("EOF.");
?>
Expected result:
A warning message have been sent to server log and a full page should have
been returned to a client.
Actual result:
--
PHP crashes at line marked with "XXX". The problem seems to be related to
the fact that the error is generated with incorrect call to split().
--
Edit bug report at http://bugs.php.net/?id=30798&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30798&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30798&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30798&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30798&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30798&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30798&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30798&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30798&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30798&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30798&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30798&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30798&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30798&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30798&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30798&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30798&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30798&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30798&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30798&r=mysqlcfg
