#38274 [Opn]: Memlimit fatal error sent to "wrong" stderr when using fastcgi
ID: 38274 User updated by: ch at hoffie dot info Reported By: ch at hoffie dot info Status: Open Bug Type: CGI related Operating System: Linux -PHP Version: 5.2.0RC5 +PHP Version: 5.2.0 New Comment: And the final contains this bug as well... Previous Comments: [2006-10-08 10:22:53] ch at hoffie dot info Still reproducable with rc5... Seems it isn't going to be fixed until the final will be released... [2006-09-01 12:49:32] ch at hoffie dot info It's still reproducable with 5.2.0RC3. It's annoying to see empty pages instead of error messages in development (where you may expect error messages to be served by the webserver). Was my description not clear enough? [2006-07-31 20:13:26] ch at hoffie dot info Description: When using the FastCGI SAPI the error message when the memory limit is exceeded (Fatal error: Allowed memory size ... exhausted) is sometimes sent to the real stderr (the pipe) instead of the stderr within the FastCGI protocol (which the FastCGI client would handle). This only occurs in special circumstances. The code procudes an error regarding the memory limit too, but it is displayed correctly (on the "right" stderr, the FastCGI's one). Sending the same error to different targets sounds inconsistent to me. The problem didn't exist in PHP 5.1.4. Maybe it is related to http://bugs.php.net/bug.php?id=37481? Reproduce code: --- Request a file containing from a webserver which is configured to serve PHP files via FastCGI. Expected result: The message Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /var/www/localhost/htdocs/a.php on line 1 should be served by the webserver (assuming display_errors=1 and error_reporting(E_ALL)) to the client. Additionally the data sent to the FastCGI socket seems to be corrupt (I didn't analyze it, but my own implementation had problems, and lighttpd seems to have canceled the request, my browser tried to download the PHP file (without content of course)). Actual result: -- On the console, the webserver (or FastCGI server) was started on, Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /var/www/localhost/htdocs/a.php on line 1 is displayed. -- Edit this bug report at http://bugs.php.net/?id=38274&edit=1
#38274 [Opn]: Memlimit fatal error sent to "wrong" stderr when using fastcgi
ID: 38274 User updated by: ch at hoffie dot info Reported By: ch at hoffie dot info Status: Open Bug Type: CGI related Operating System: Linux -PHP Version: 5.2.0RC3 +PHP Version: 5.2.0RC5 New Comment: Still reproducable with rc5... Seems it isn't going to be fixed until the final will be released... Previous Comments: [2006-09-01 12:49:32] ch at hoffie dot info It's still reproducable with 5.2.0RC3. It's annoying to see empty pages instead of error messages in development (where you may expect error messages to be served by the webserver). Was my description not clear enough? [2006-07-31 20:13:26] ch at hoffie dot info Description: When using the FastCGI SAPI the error message when the memory limit is exceeded (Fatal error: Allowed memory size ... exhausted) is sometimes sent to the real stderr (the pipe) instead of the stderr within the FastCGI protocol (which the FastCGI client would handle). This only occurs in special circumstances. The code procudes an error regarding the memory limit too, but it is displayed correctly (on the "right" stderr, the FastCGI's one). Sending the same error to different targets sounds inconsistent to me. The problem didn't exist in PHP 5.1.4. Maybe it is related to http://bugs.php.net/bug.php?id=37481? Reproduce code: --- Request a file containing from a webserver which is configured to serve PHP files via FastCGI. Expected result: The message Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /var/www/localhost/htdocs/a.php on line 1 should be served by the webserver (assuming display_errors=1 and error_reporting(E_ALL)) to the client. Additionally the data sent to the FastCGI socket seems to be corrupt (I didn't analyze it, but my own implementation had problems, and lighttpd seems to have canceled the request, my browser tried to download the PHP file (without content of course)). Actual result: -- On the console, the webserver (or FastCGI server) was started on, Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /var/www/localhost/htdocs/a.php on line 1 is displayed. -- Edit this bug report at http://bugs.php.net/?id=38274&edit=1
#38274 [Opn]: Memlimit fatal error sent to "wrong" stderr when using fastcgi
ID: 38274 User updated by: ch at hoffie dot info Reported By: ch at hoffie dot info Status: Open Bug Type: CGI related Operating System: Linux -PHP Version: 5CVS-2006-07-31 (snap) +PHP Version: 5.2.0RC3 New Comment: It's still reproducable with 5.2.0RC3. It's annoying to see empty pages instead of error messages in development (where you may expect error messages to be served by the webserver). Was my description not clear enough? Previous Comments: [2006-07-31 20:13:26] ch at hoffie dot info Description: When using the FastCGI SAPI the error message when the memory limit is exceeded (Fatal error: Allowed memory size ... exhausted) is sometimes sent to the real stderr (the pipe) instead of the stderr within the FastCGI protocol (which the FastCGI client would handle). This only occurs in special circumstances. The code procudes an error regarding the memory limit too, but it is displayed correctly (on the "right" stderr, the FastCGI's one). Sending the same error to different targets sounds inconsistent to me. The problem didn't exist in PHP 5.1.4. Maybe it is related to http://bugs.php.net/bug.php?id=37481? Reproduce code: --- Request a file containing from a webserver which is configured to serve PHP files via FastCGI. Expected result: The message Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /var/www/localhost/htdocs/a.php on line 1 should be served by the webserver (assuming display_errors=1 and error_reporting(E_ALL)) to the client. Additionally the data sent to the FastCGI socket seems to be corrupt (I didn't analyze it, but my own implementation had problems, and lighttpd seems to have canceled the request, my browser tried to download the PHP file (without content of course)). Actual result: -- On the console, the webserver (or FastCGI server) was started on, Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /var/www/localhost/htdocs/a.php on line 1 is displayed. -- Edit this bug report at http://bugs.php.net/?id=38274&edit=1
#38274 [NEW]: Memlimit fatal error sent to "wrong" stderr when using fastcgi
From: ch at hoffie dot info Operating system: Linux PHP version: 5CVS-2006-07-31 (snap) PHP Bug Type: CGI related Bug description: Memlimit fatal error sent to "wrong" stderr when using fastcgi Description: When using the FastCGI SAPI the error message when the memory limit is exceeded (Fatal error: Allowed memory size ... exhausted) is sometimes sent to the real stderr (the pipe) instead of the stderr within the FastCGI protocol (which the FastCGI client would handle). This only occurs in special circumstances. The code procudes an error regarding the memory limit too, but it is displayed correctly (on the "right" stderr, the FastCGI's one). Sending the same error to different targets sounds inconsistent to me. The problem didn't exist in PHP 5.1.4. Maybe it is related to http://bugs.php.net/bug.php?id=37481? Reproduce code: --- Request a file containing from a webserver which is configured to serve PHP files via FastCGI. Expected result: The message Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /var/www/localhost/htdocs/a.php on line 1 should be served by the webserver (assuming display_errors=1 and error_reporting(E_ALL)) to the client. Additionally the data sent to the FastCGI socket seems to be corrupt (I didn't analyze it, but my own implementation had problems, and lighttpd seems to have canceled the request, my browser tried to download the PHP file (without content of course)). Actual result: -- On the console, the webserver (or FastCGI server) was started on, Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /var/www/localhost/htdocs/a.php on line 1 is displayed. -- Edit bug report at http://bugs.php.net/?id=38274&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38274&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38274&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38274&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38274&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38274&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38274&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38274&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38274&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38274&r=support Expected behavior:http://bugs.php.net/fix.php?id=38274&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38274&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38274&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38274&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38274&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38274&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38274&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38274&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38274&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38274&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38274&r=mysqlcfg
#38183 [NEW]: disable_classes=Directory introduces new class "dir"?
From: ch at hoffie dot info
Operating system: Linux 2.6
PHP version: 5.1.4
PHP Bug Type: PHP options/info functions
Bug description: disable_classes=Directory introduces new class "dir"?
Description:
With disable_classes=Directory in the php.ini file, get_declared_classes()
no longer returns the "Directory" class, but a class called "dir".
[This bug still exists in PHP 5.2, there you could also use "Date" (which
results in "dat") or "Reflection..." (result: "ref") instead of
Directory/dir (so Directory is not an exception, it's a general issue).]
Reproduce code:
---
[EMAIL PROTECTED] ~ $ echo "disable_classes=Directory" > /tmp/php.ini
[EMAIL PROTECTED] ~ $ php -c /tmp/php.ini -r 'var_dump(in_array("Directory",
get_declared_classes()), in_array("dir", get_declared_classes())); new
dir();'
Expected result:
bool(true)
bool(false)
Fatal error: Class 'dir' not found in Command line code on line 1
Actual result:
--
bool(false)
bool(true)
Warning: directory() has been disabled for security reasons in Command
line code on line 1
--
Edit bug report at http://bugs.php.net/?id=38183&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38183&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38183&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38183&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38183&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38183&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38183&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38183&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38183&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38183&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38183&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38183&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38183&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38183&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38183&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38183&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38183&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38183&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38183&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38183&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38183&r=mysqlcfg
