Req #54033 [ReO-Csd]: add get_error_handler and get_exception handler
Edit report at https://bugs.php.net/bug.php?id=54033edit=1 ID: 54033 User updated by:tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:add get_error_handler and get_exception handler -Status: Re-Opened +Status: Closed Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.3.5 Block user comment: N Private report: N New Comment: test Previous Comments: [2011-02-18 11:45:20] tyra3l at gmail dot com the get_exception_handler is least important for me: I cannot come up with a situation, which couldn't be solved by set_exception_handler and restore_exception_handler, because the exception handler doesn't have something like the $error_types in the set_error_handler. but I think it would be more consistent if both the error and exception handler functions would provide that. Tyrael [2011-02-17 01:04:00] tyra3l at gmail dot com of course it returns the callback. but: - you can't get it without overwriting - it doesn't return the error_types, hence you won't know on which error should you call the previous handler - if you would think, that maybe the restore_error_handler would come to the rescue(you set your error handler, in your error handler you catch everything, and restore the previous handler for the errors that isn't for you and and call the original error handler with trigger_error): you can only tigger E_USER_*. :( am I missing something? if not, please re-open the issue, because it isn't bogus. Tyrael [2011-02-17 00:50:53] ras...@php.net set_error_handler() already returns the previously set error handler, if any. [2011-02-17 00:44:58] tyra3l at gmail dot com Description: my co-worker had a problem with the Zend Framework Soap Server class: he was using trigger_error for handling the application level errors, and the ZF Soap Server class set his own error_handler, so my co-worker's error handler was swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you have an userspace error handler then every error type, which isn't observed will be discarded) I mentioned this on twitter (I wasn't really nice) http://twitter.com/#!/Tyr43l/status/22704699030 and Matthew Weier O'Phinney responded that they had to do this, because there was some quirks about the SoapServer or DomDocument class. so if they don't set their error_handler, they can't handle the error, if they do, they will overwrite any existing error_handler. if there would be a way, to get the current(previous) error handler, then they could have save the current/previous error handler (with the error type parameter!) and from their error handler, they could have call the applevel error handler callback. of course, some stackable mechanism, like the spl_autoload would be a more better approach but that would break BC, at least I couldn't figure out a way to do it without problems. I will ask Matthew to comment on this issue (what was the exact problem that forced them to set the error handler at the first place) -- Edit this bug report at https://bugs.php.net/bug.php?id=54033edit=1
Req #54033 [Csd-Asn]: add get_error_handler and get_exception handler
Edit report at https://bugs.php.net/bug.php?id=54033edit=1 ID: 54033 User updated by:tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:add get_error_handler and get_exception handler -Status: Closed +Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.3.5 Block user comment: N Private report: N New Comment: asd Previous Comments: [2012-03-18 16:41:41] tyra3l at gmail dot com test [2011-02-18 11:45:20] tyra3l at gmail dot com the get_exception_handler is least important for me: I cannot come up with a situation, which couldn't be solved by set_exception_handler and restore_exception_handler, because the exception handler doesn't have something like the $error_types in the set_error_handler. but I think it would be more consistent if both the error and exception handler functions would provide that. Tyrael [2011-02-17 01:04:00] tyra3l at gmail dot com of course it returns the callback. but: - you can't get it without overwriting - it doesn't return the error_types, hence you won't know on which error should you call the previous handler - if you would think, that maybe the restore_error_handler would come to the rescue(you set your error handler, in your error handler you catch everything, and restore the previous handler for the errors that isn't for you and and call the original error handler with trigger_error): you can only tigger E_USER_*. :( am I missing something? if not, please re-open the issue, because it isn't bogus. Tyrael [2011-02-17 00:50:53] ras...@php.net set_error_handler() already returns the previously set error handler, if any. [2011-02-17 00:44:58] tyra3l at gmail dot com Description: my co-worker had a problem with the Zend Framework Soap Server class: he was using trigger_error for handling the application level errors, and the ZF Soap Server class set his own error_handler, so my co-worker's error handler was swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you have an userspace error handler then every error type, which isn't observed will be discarded) I mentioned this on twitter (I wasn't really nice) http://twitter.com/#!/Tyr43l/status/22704699030 and Matthew Weier O'Phinney responded that they had to do this, because there was some quirks about the SoapServer or DomDocument class. so if they don't set their error_handler, they can't handle the error, if they do, they will overwrite any existing error_handler. if there would be a way, to get the current(previous) error handler, then they could have save the current/previous error handler (with the error type parameter!) and from their error handler, they could have call the applevel error handler callback. of course, some stackable mechanism, like the spl_autoload would be a more better approach but that would break BC, at least I couldn't figure out a way to do it without problems. I will ask Matthew to comment on this issue (what was the exact problem that forced them to set the error handler at the first place) -- Edit this bug report at https://bugs.php.net/bug.php?id=54033edit=1
Req #54033 [Csd-Asn]: add get_error_handler and get_exception handler
Edit report at https://bugs.php.dev/bug.php?id=54033edit=1 ID: 54033 User updated by:tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:add get_error_handler and get_exception handler -Status: Closed +Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.3.5 Assigned To:tyrael Block user comment: N Private report: N New Comment: hi Previous Comments: [2012-03-18 17:52:10] tyr...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2011-02-18 11:45:20] tyra3l at gmail dot com the get_exception_handler is least important for me: I cannot come up with a situation, which couldn't be solved by set_exception_handler and restore_exception_handler, because the exception handler doesn't have something like the $error_types in the set_error_handler. but I think it would be more consistent if both the error and exception handler functions would provide that. Tyrael [2011-02-17 01:04:00] tyra3l at gmail dot com of course it returns the callback. but: - you can't get it without overwriting - it doesn't return the error_types, hence you won't know on which error should you call the previous handler - if you would think, that maybe the restore_error_handler would come to the rescue(you set your error handler, in your error handler you catch everything, and restore the previous handler for the errors that isn't for you and and call the original error handler with trigger_error): you can only tigger E_USER_*. :( am I missing something? if not, please re-open the issue, because it isn't bogus. Tyrael [2011-02-17 00:50:53] ras...@php.net set_error_handler() already returns the previously set error handler, if any. [2011-02-17 00:44:58] tyra3l at gmail dot com Description: my co-worker had a problem with the Zend Framework Soap Server class: he was using trigger_error for handling the application level errors, and the ZF Soap Server class set his own error_handler, so my co-worker's error handler was swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you have an userspace error handler then every error type, which isn't observed will be discarded) I mentioned this on twitter (I wasn't really nice) http://twitter.com/#!/Tyr43l/status/22704699030 and Matthew Weier O'Phinney responded that they had to do this, because there was some quirks about the SoapServer or DomDocument class. so if they don't set their error_handler, they can't handle the error, if they do, they will overwrite any existing error_handler. if there would be a way, to get the current(previous) error handler, then they could have save the current/previous error handler (with the error type parameter!) and from their error handler, they could have call the applevel error handler callback. of course, some stackable mechanism, like the spl_autoload would be a more better approach but that would break BC, at least I couldn't figure out a way to do it without problems. I will ask Matthew to comment on this issue (what was the exact problem that forced them to set the error handler at the first place) -- Edit this bug report at https://bugs.php.dev/bug.php?id=54033edit=1
Req #54383 [Com]: extend the usage of session_encode/session_decode
Edit report at https://bugs.php.net/bug.php?id=54383edit=1 ID: 54383 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:extend the usage of session_encode/session_decode Status: Open Type: Feature/Change Request Package:Session related PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I don't see your point. as I mentioned, this change would be backward compatible, because by default, the behavior would be the same, but it would be possible to encode/decode the session from/to an arbitary variable. Tyrael Previous Comments: [2011-07-02 19:23:39] arraypad at gmail dot com The problem with this is that we currently expect the (possibly custom) serializer to work directly on the $_SESSION array. Changing this would be a big BC break in the session API. [2011-03-25 16:16:33] tyra3l at gmail dot com Description: I always wondered about the rationale about the session_encode/decode in it's current form, but Chris Shiflett's blogpost made me to open this bugreport: http://shiflett.org/blog/2011/mar/php-session-debugging I would propose two changes: - add a new optional array argument for session_encode, if it is passed, then encode that instead of the $_SESSION array. - add a new optional boolean argument for session_decode, if that sets to true (default is false), then the decoded session array is returned instead of inserted to $_SESSION obviously the documentation about the return variable for session_decode should also be updated to reflect this change. this should be backward compatible change, but it would allow us to encode/decode an arbitary serialized session without the need to save and reload the contents of the current $_SESSION array. -- Edit this bug report at https://bugs.php.net/bug.php?id=54383edit=1
Bug #54600 [Com]: possible parse_url problem
Edit report at http://bugs.php.net/bug.php?id=54600edit=1
ID: 54600
Comment by: tyra3l at gmail dot com
Reported by:tyra3l at gmail dot com
Summary:possible parse_url problem
Status: Bogus
Type: Bug
Package:*URL Functions
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
so it seems we are going with the last option: leave this as is.
Tyrael
Previous Comments:
[2011-05-29 11:02:02] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2011-04-25 11:19:09] tyra3l at gmail dot com
Description:
I've just read this article:
http://theharmonyguy.com/2011/04/21/recent-facebook-xss-attacks-show-increasing-
sophistication/
there is an interesting part:
According to Facebook, it turned out that some older code was using
PHPâs
built-in parse_url function to determine allowable URLs. For example,
while
parse_url(âjavascript:alert(1)â) yields a scheme of âjavascriptâ
and a path of
âalert(1)â, adding whitespace gives a different result:
parse_url(â
javascript:alert(1)â) does not return a scheme and has a path of
âjavascript:alert(1)â. Other PHP developers should take note of the
difference
if parse_url is being used in security-related code.
I know that the documentation mentions that This function is not meant
to
validate the given URL, it only breaks it up into the above listed
parts. but
maybe we should do something to prevent people to misuse this function.
I see 4 option:
- we should improve the code to strip whitespaces that would cause the
function
to return the same output for the forged url's
- we should change te code that the function never parse javascript: as
scheme,
this would prevent the people to use parse_url for this purpose, but
judging
from the article at least some code on facebook would fail insecurely
for this
change.
- we should add more documentation about this issue, it can help, but I
don't
think that this would be the best fix.
- leave it as is, we documented that one should not use this for
validation, we
can't save people from their bad code. Personally I'm not supporting
this
option.
What do you think?
Test script:
---
php -r 'var_dump(parse_url(javascript:alert(1)));'
array(2) {
[scheme]=
string(10) javascript
[path]=
string(8) alert(1)
}
php -r 'var_dump(parse_url( javascript:alert(1)));'
array(1) {
[path]=
string(20) javascript:alert(1)
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=54600edit=1
Req #39863 [Com]: file_exists() silently truncates after a null byte
Edit report at http://bugs.php.net/bug.php?id=39863edit=1 ID: 39863 Comment by: tyra3l at gmail dot com Reported by:djcapelis at gmail dot com Summary:file_exists() silently truncates after a null byte Status: Assigned Type: Feature/Change Request Package:*General Issues Operating System: Linux, MacOSX PHP Version:4.4.4, 5.1.5 Assigned To:pajoye Block user comment: N Private report: N CVE-ID: 2006-7243 New Comment: the testcase a little bit confusing: it should fail until the bug is fixed, and because it was a known bug, it was marked as a failing test (XFAIL) now that the bug got fixed, but the test wasn't modified to reflect this, we got a situation, when an test passed when it is expected to fail. which means that the bug is fixed. I will modify the TEST and remove the XFAIL mark, and if the pass fails in the future, that means that we got a regression. Tyrael Previous Comments: [2011-04-14 15:00:34] paul dot kraus at ag dot ny dot gov Just compiled 5.3.6 on Solaris 10 / SPARC and `make test` reports Bug #39863 (file_exists() silently truncates after a null byte) [ext/standard/test/file/bug39863.phpt] (warn: XFAIL section but test passes) so it appears that this bug is NOT fixed as of 5.3.6 on Solaris 10 (unless I am misreading the test report). [2011-01-19 13:13:52] patrick at cookie dot monster dot org Will this be fixed too in php 5.2.17? [2010-11-18 17:21:15] paj...@php.net Fixed in PHP_5_3, will be part of 5.3.4. trunk still needs the fix, it will be done soonish. [2010-11-18 16:22:24] paj...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=305507 Log: - fix #39863, do not accept paths with NULL in them. See http://news.php.net/php.internals/50191, trunk will have the patch later (adding a macro and/or changing (some) APIs. Patch by Rasmus [2010-06-05 21:45:27] s...@php.net I've merged the test as ext/standard/tests/file/bug39863.phpt The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=39863 -- Edit this bug report at http://bugs.php.net/bug.php?id=39863edit=1
Bug #54570 [Com]: SPLFileObject returns the content of a file after it was deleted
Edit report at http://bugs.php.net/bug.php?id=54570edit=1
ID: 54570
Comment by: tyra3l at gmail dot com
Reported by:bugs dot php at mohiva dot com
Summary:SPLFileObject returns the content of a file after it
was deleted
Status: Open
Type: Bug
Package:SPL related
Operating System: Gentoo Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
http://stackoverflow.com/questions/196897/locking-executing-files-windows-does-
linux-doesnt-why/196908#196908
Tyrael
Previous Comments:
[2011-04-19 22:46:01] bugs dot php at mohiva dot com
Description:
With SPLFileObject it is possible to return the content of a file, after
the file was deleted.
Test script:
---
file_put_contents('/tmp/file.txt', 'test');
$file = new SplFileObject('/tmp/file.txt');
unlink('/tmp/file.txt');
var_dump(file_exists('/tmp/file.txt'));
while (!$file-eof()) {
echo $file-fgets();
}
Expected result:
bool(false)
Actual result:
--
bool(false)
test
--
Edit this bug report at http://bugs.php.net/bug.php?id=54570edit=1
Bug #54570 [Com]: SPLFileObject returns the content of a file after it was deleted
Edit report at http://bugs.php.net/bug.php?id=54570edit=1
ID: 54570
Comment by: tyra3l at gmail dot com
Reported by:bugs dot php at mohiva dot com
Summary:SPLFileObject returns the content of a file after it
was deleted
Status: Open
Type: Bug
Package:SPL related
Operating System: Gentoo Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
shorter url:
http://bit.ly/kdhzpQ
it is normal that you can access a deleted file if you have an open file
descriptor for that file.
and this is exactly what happens here
Tyrael
Previous Comments:
[2011-04-29 00:17:49] tyra3l at gmail dot com
http://stackoverflow.com/questions/196897/locking-executing-files-windows-does-
linux-doesnt-why/196908#196908
Tyrael
[2011-04-19 22:46:01] bugs dot php at mohiva dot com
Description:
With SPLFileObject it is possible to return the content of a file, after
the file was deleted.
Test script:
---
file_put_contents('/tmp/file.txt', 'test');
$file = new SplFileObject('/tmp/file.txt');
unlink('/tmp/file.txt');
var_dump(file_exists('/tmp/file.txt'));
while (!$file-eof()) {
echo $file-fgets();
}
Expected result:
bool(false)
Actual result:
--
bool(false)
test
--
Edit this bug report at http://bugs.php.net/bug.php?id=54570edit=1
[PHP-BUG] Bug #54600 [NEW]: possible parse_url problem
From:
Operating system:
PHP version: 5.3.6
Package: *URL Functions
Bug Type: Bug
Bug description:possible parse_url problem
Description:
I've just read this article:
http://theharmonyguy.com/2011/04/21/recent-facebook-xss-attacks-show-increasing-
sophistication/
there is an interesting part:
According to Facebook, it turned out that some older code was using
PHPâs
built-in parse_url function to determine allowable URLs. For example, while
parse_url(âjavascript:alert(1)â) yields a scheme of âjavascriptâ
and a path of
âalert(1)â, adding whitespace gives a different result: parse_url(â
javascript:alert(1)â) does not return a scheme and has a path of
âjavascript:alert(1)â. Other PHP developers should take note of the
difference
if parse_url is being used in security-related code.
I know that the documentation mentions that This function is not meant to
validate the given URL, it only breaks it up into the above listed parts.
but
maybe we should do something to prevent people to misuse this function.
I see 4 option:
- we should improve the code to strip whitespaces that would cause the
function
to return the same output for the forged url's
- we should change te code that the function never parse javascript: as
scheme,
this would prevent the people to use parse_url for this purpose, but
judging
from the article at least some code on facebook would fail insecurely for
this
change.
- we should add more documentation about this issue, it can help, but I
don't
think that this would be the best fix.
- leave it as is, we documented that one should not use this for
validation, we
can't save people from their bad code. Personally I'm not supporting this
option.
What do you think?
Test script:
---
php -r 'var_dump(parse_url(javascript:alert(1)));'
array(2) {
[scheme]=
string(10) javascript
[path]=
string(8) alert(1)
}
php -r 'var_dump(parse_url( javascript:alert(1)));'
array(1) {
[path]=
string(20) javascript:alert(1)
}
--
Edit bug report at http://bugs.php.net/bug.php?id=54600edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54600r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54600r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54600r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54600r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54600r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54600r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54600r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54600r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54600r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54600r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54600r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54600r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54600r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54600r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54600r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54600r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54600r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54600r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54600r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54600r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54600r=mysqlcfg
[PHP-BUG] Req #54603 [NEW]: implement posix_setrlimit
From: Operating system: PHP version: 5.3.6 Package: POSIX related Bug Type: Feature/Change Request Bug description:implement posix_setrlimit Description: we have a posix_getrlimit, it would be nice to have the posix_setrlimit also. it whould be trivial to implement, so maybe there is a reason that we didn't provide this functionality. -- Edit bug report at http://bugs.php.net/bug.php?id=54603edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54603r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54603r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54603r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54603r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54603r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54603r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54603r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54603r=needscript Try newer version: http://bugs.php.net/fix.php?id=54603r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54603r=support Expected behavior: http://bugs.php.net/fix.php?id=54603r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54603r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54603r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54603r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54603r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54603r=dst IIS Stability: http://bugs.php.net/fix.php?id=54603r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54603r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54603r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54603r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54603r=mysqlcfg
Req #41310 [Com]: make extension_dir optional and use absolute paths in extension = ...
Edit report at http://bugs.php.net/bug.php?id=41310edit=1 ID: 41310 Comment by: tyra3l at gmail dot com Reported by:mastamind at users dot sourceforge dot net Summary:make extension_dir optional and use absolute paths in extension = ... Status: Open Type: Feature/Change Request Package:PHP options/info functions Operating System: * PHP Version:* Block user comment: N Private report: N New Comment: it works for me with 5.3.6: extension /usr/lib/php5/20090626/pdo.so correctly loads the pdo extension from the absolute path. Tyrael Previous Comments: [2010-12-29 11:45:59] j...@php.net See also bug #9095 [2007-05-07 00:44:27] mastamind at users dot sourceforge dot net Description: using extension_dir = /usr/local/lib/php extension = ../pgsql.so makes php search for pgsql.so in /usr/local/lib. It would be nice if php allows absolute paths for extension loading: extension = /usr/local/lib/pgsql.so as specifing it relative to the extension_dir is quite strange and probably makes extension_dir useless. specifing absolute paths with dl() may result in a security problem, but using it in php.ini may be ok. -- Edit this bug report at http://bugs.php.net/bug.php?id=41310edit=1
[PHP-BUG] Req #54564 [NEW]: extension_dir should be used for loading zend_extensions
From: Operating system: PHP version: 5.3.6 Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:extension_dir should be used for loading zend_extensions Description: I've brought this topic on the internals http://marc.info/?l=php-internalsm=130314285822279w=2 and I think that it would be useful and more consistent, if this could be changed, so one could easily load both normal and zend extensions without the need to use absolute paths. Test script: --- php -n -d zend_extension=xdebug.so -r '' Actual result: -- Failed loading xdebug.so: xdebug.so: cannot open shared object file: No such file or directory -- Edit bug report at http://bugs.php.net/bug.php?id=54564edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54564r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54564r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54564r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54564r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54564r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54564r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54564r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54564r=needscript Try newer version: http://bugs.php.net/fix.php?id=54564r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54564r=support Expected behavior: http://bugs.php.net/fix.php?id=54564r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54564r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54564r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54564r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54564r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54564r=dst IIS Stability: http://bugs.php.net/fix.php?id=54564r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54564r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54564r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54564r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54564r=mysqlcfg
[PHP-BUG] Req #54537 [NEW]: production value for html_errors should be On
From: Operating system: PHP version: 5.3.6 Package: *Configuration Issues Bug Type: Feature/Change Request Bug description:production value for html_errors should be On Description: I've noticed, that we suggest setting the html_errors in production to Off, which is an odd thing: in production one should display errors, but if he does, then I can't see why would be more appropriate not to use html errors. could you elaborate on this please? -- Edit bug report at http://bugs.php.net/bug.php?id=54537edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54537r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54537r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54537r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54537r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54537r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54537r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54537r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54537r=needscript Try newer version: http://bugs.php.net/fix.php?id=54537r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54537r=support Expected behavior: http://bugs.php.net/fix.php?id=54537r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54537r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54537r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54537r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54537r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54537r=dst IIS Stability: http://bugs.php.net/fix.php?id=54537r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54537r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54537r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54537r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54537r=mysqlcfg
Req #54537 [Com]: production value for html_errors should be On
Edit report at http://bugs.php.net/bug.php?id=54537edit=1 ID: 54537 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:production value for html_errors should be On Status: Open Type: Feature/Change Request Package:*Configuration Issues PHP Version:5.3.6 Block user comment: N Private report: N New Comment: sorry, I can't follow you. Is a dynamic plain text web page that hard to imagine? no, but the majority of the php sites out there use html as the primary output type. you can turn off the html_errors if you are dealing with plain text files. I know the CLI SAPI has html_errors = 0 hard coded in but why force people to turn off an option that provides little to no benefit... so only the apache SAPI would be affected, where the majority of the users use html output. but I think that this option should affect anything in a production system, because you turn off the error_reporting in production (and PHP also suggests that, so any distribution which follows the suggestions of the php.ini-* files wouldn't be affected by this change. at all) and both error_reporting and html_errors is enabled in the php.ini-development, so for the text/plain people that would be a problem also. Tyrael Previous Comments: [2011-04-15 21:47:55] dtajchre...@php.net Is a dynamic plain text web page that hard to imagine? What about non browser output? I know the CLI SAPI has html_errors = 0 hard coded in but why force people to turn off an option that provides little to no benefit... [2011-04-15 17:04:24] der...@php.net I agree. There is no reason why html_errors should be off in any case. Especially because the reasoning is non-sense. [2011-04-15 12:18:12] tyra3l at gmail dot com Description: I've noticed, that we suggest setting the html_errors in production to Off, which is an odd thing: in production one should display errors, but if he does, then I can't see why would be more appropriate not to use html errors. could you elaborate on this please? -- Edit this bug report at http://bugs.php.net/bug.php?id=54537edit=1
Req #54537 [Com]: production value for html_errors should be On
Edit report at http://bugs.php.net/bug.php?id=54537edit=1 ID: 54537 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:production value for html_errors should be On Status: Open Type: Feature/Change Request Package:*Configuration Issues PHP Version:5.3.6 Block user comment: N Private report: N New Comment: probably you know, but you can re-enable html_errors for cli via ini_set: http://www.php.net/manual/en/features.commandline.differences.php for example: php -d display_errors=1 -d error_reporting=-1 -r 'ini_set(html_errors, 1);trigger_error(foo, E_USER_NOTICE);' Tyrael Previous Comments: [2011-04-15 22:16:21] tyra3l at gmail dot com sorry, I can't follow you. Is a dynamic plain text web page that hard to imagine? no, but the majority of the php sites out there use html as the primary output type. you can turn off the html_errors if you are dealing with plain text files. I know the CLI SAPI has html_errors = 0 hard coded in but why force people to turn off an option that provides little to no benefit... so only the apache SAPI would be affected, where the majority of the users use html output. but I think that this option should affect anything in a production system, because you turn off the error_reporting in production (and PHP also suggests that, so any distribution which follows the suggestions of the php.ini-* files wouldn't be affected by this change. at all) and both error_reporting and html_errors is enabled in the php.ini-development, so for the text/plain people that would be a problem also. Tyrael [2011-04-15 21:47:55] dtajchre...@php.net Is a dynamic plain text web page that hard to imagine? What about non browser output? I know the CLI SAPI has html_errors = 0 hard coded in but why force people to turn off an option that provides little to no benefit... [2011-04-15 17:04:24] der...@php.net I agree. There is no reason why html_errors should be off in any case. Especially because the reasoning is non-sense. [2011-04-15 12:18:12] tyra3l at gmail dot com Description: I've noticed, that we suggest setting the html_errors in production to Off, which is an odd thing: in production one should display errors, but if he does, then I can't see why would be more appropriate not to use html errors. could you elaborate on this please? -- Edit this bug report at http://bugs.php.net/bug.php?id=54537edit=1
Req #42516 [Com]: __FILE__ resolves symlinks
Edit report at http://bugs.php.net/bug.php?id=42516edit=1 ID: 42516 Comment by: tyra3l at gmail dot com Reported by:michael at zedeler dot dk Summary:__FILE__ resolves symlinks Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem Operating System: Linux PHP Version:4.4.7 Assigned To:bjori Block user comment: N Private report: N New Comment: $_SERVER[SCRIPT_FILENAME] can be used for getting the non-resolved path, and the documentation at http://php.net/manual/en/language.constants.predefined.php now contains info about __FILE__ is resolved to absolute path with resolved symlinks. so I think that this could be closed. Tyrael Previous Comments: [2009-08-17 12:57:30] michael at zedeler dot dk Fixed subject. [2009-08-17 12:56:08] michael at zedeler dot dk Moved to Feature/Change request category. [2009-04-24 05:58:24] bj...@php.net Please use the developers mailinglist for feature discussions (intern...@lists.php.net). [2009-04-23 17:53:20] michael at zedeler dot dk Sorry to bug you again, but as I am writing in the report, just putting a description of the errant behaviour is not a useful fix. [2007-09-01 21:02:38] michael at zedeler dot dk Description: __FILE__ does not return the path used to invoke the current file, but resolves symlinks. This behaviour is extremely problematics, since important information is thrown away. The web is teeming with postings from people that are experiencing problems because of this. In http://bugs.php.net/bug.php?id=37603 this bug was mentioned and the response was that it is intended behavior with a reference to the manual. The page http://es.php.net/manual/en/language.constants.predefined.php is the primary source of information for __FILE__, and it does not mention resolving symlinks at all. I'd like if we could have som kind of dialogue about how to solve the problem, in stead of just having this bug being closed with a Bogus status. My suggestions are: 1) introduce a new magical constant that behaves as it should. 2) put a parameter in php.ini that changes how __FILE__ behaves. Reproduce code: --- This is basically a reopening of http://bugs.php.net/bug.php?id=37603 Expected result: This is basically a reopening of http://bugs.php.net/bug.php?id=37603 Actual result: -- This is basically a reopening of http://bugs.php.net/bug.php?id=37603 -- Edit this bug report at http://bugs.php.net/bug.php?id=42516edit=1
Req #54032 [Com]: ability to to handle Class not found error
Edit report at http://bugs.php.net/bug.php?id=54032edit=1 ID: 54032 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:ability to to handle Class not found error Status: Open Type: Feature/Change Request Package:SPL related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: after some sleep and a little bit thinking, I think that the best solution would be to introduce a new Exception type, which will be thrown if the execution of the autoload callbacks doesn't successfully load the class. what do you think? Tyrael Previous Comments: [2011-02-17 00:15:36] tyra3l at gmail dot com *exists - exit *exection - execution * spl autoload callbacks was executed - spl autoload callbacks was executed without finding the class * I cannot continue the normal execution flow - I couldn't continue the normal execution flow * from a higher level - at a higher level sorry, its getting late, and my english skill degrades with sleep deprivation [2011-02-17 00:11:01] tyra3l at gmail dot com Description: currently you can throw an exception from the autoloader, hence if you can't find a class, your application can gracefully exists, instead of exiting via the class not found fatal error. my problem is, that I would like to use multiple autoloader (for example in a project which uses multiple component, or framework), but in this case, I can't throw an Exception from my autoloader, because maybe the other autoloaders could load the class. if I'm sure that I will register the last autoloader, the this isn't a problem(my last autoloader will throw the Exception on missing class), but maybe I have to load a component late of the exection. it would be cool, if I could somehow register a callback which will be called, when the spl autoload callbacks was executed, but the class couldn't be loaded of course, from this callback, I cannot continue the normal execution flow, however I can log the error, and let the callback return and get the class not found fatal error, or throw an Exception, and handle/log the error from a higher level. -- Edit this bug report at http://bugs.php.net/bug.php?id=54032edit=1
[PHP-BUG] Req #54383 [NEW]: extend the usage of session_encode/session_decode
From: Operating system: PHP version: 5.3.6 Package: Session related Bug Type: Feature/Change Request Bug description:extend the usage of session_encode/session_decode Description: I always wondered about the rationale about the session_encode/decode in it's current form, but Chris Shiflett's blogpost made me to open this bugreport: http://shiflett.org/blog/2011/mar/php-session-debugging I would propose two changes: - add a new optional array argument for session_encode, if it is passed, then encode that instead of the $_SESSION array. - add a new optional boolean argument for session_decode, if that sets to true (default is false), then the decoded session array is returned instead of inserted to $_SESSION obviously the documentation about the return variable for session_decode should also be updated to reflect this change. this should be backward compatible change, but it would allow us to encode/decode an arbitary serialized session without the need to save and reload the contents of the current $_SESSION array. -- Edit bug report at http://bugs.php.net/bug.php?id=54383edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54383r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54383r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54383r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54383r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54383r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54383r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54383r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54383r=needscript Try newer version: http://bugs.php.net/fix.php?id=54383r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54383r=support Expected behavior: http://bugs.php.net/fix.php?id=54383r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54383r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54383r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54383r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54383r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54383r=dst IIS Stability: http://bugs.php.net/fix.php?id=54383r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54383r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54383r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54383r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54383r=mysqlcfg
Bug #54195 [Com]: The notorious Call to a member function .. on a non-object fatal error
Edit report at http://bugs.php.net/bug.php?id=54195edit=1
ID: 54195
Comment by: tyra3l at gmail dot com
Reported by:landeholm at gmail dot com
Summary:The notorious Call to a member function .. on a
non-object fatal error
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I've mentioned this on the list, but to be archived:
AFAIK register_shutdown_function should be called on every errors, even
on the fatal ones, and it does.
at least for me, both on windows, and linux:
tyrael@devel-tyrael:~/c$ php -f fatal.php
PHP Fatal error: Call to a member function bar() on a non-object in
/home/tyrael/c/fatal.php on line 9
PHP Stack trace:
PHP 1. {main}() /home/tyrael/c/fatal.php:0
Houston we have a problem: Array
(
[type] = 1
[message] = Call to a member function bar() on a non-object
[file] = /home/tyrael/c/fatal.php
[line] = 9
)
as you can see from the output of the example code provided by Hannes
Landeholm, it does called on the fatal error.
if it doesn't work for Hannes, then I think that there are some
difference in our setup/configuration.
Tyrael
Previous Comments:
[2011-03-08 15:40:17] landeholm at gmail dot com
Description:
I had this problem a million times. It's very easy to accidentally
invoke Fatal Error: Call to a member function .. on a non-object. The
problem is that this triggers an error so fatal that it can't even be
caught by the shutdown function. This recently gave me a huge headache
in a production system where an obscure bug where a variable contain
null which was called on invoked a silent crash. It's a headache because
I run everything in a framework with great wrappers for error
handling/detection that are suppose to send me an email when obscure
bugs get tripped. This obviously doesn't work when the PHP commits
seppuku and explodes.
I don't see any reason for this error to be that fatal. Sure, keep the
error fatal but at least allow the shutdown function to catch it.
Test script:
---
\register_shutdown_function(function(){
$e = \error_get_last();
if (!\is_null($e))
die('Houston we have a problem: ' . \print_r($e, true));
});
$hello = null;
$hello-bar();
Expected result:
Houston we have a problem: Array
(
...
Actual result:
--
Fatal error: Call to a member function bar() on a non-object in ...
--
Edit this bug report at http://bugs.php.net/bug.php?id=54195edit=1
Bug #52911 [Com]: fwrite doesn't write long strings to a php stream
Edit report at http://bugs.php.net/bug.php?id=52911edit=1 ID: 52911 Comment by: tyra3l at gmail dot com Reported by:mz dot evgeny at gmail dot com Summary:fwrite doesn't write long strings to a php stream Status: Verified Type: Bug Package:*General Issues Operating System: Windows PHP Version:5.3.3 Block user comment: N Private report: N New Comment: so are we waiting for a patch, or is this a won'tfix? Tyrael Previous Comments: [2011-02-09 10:30:02] paj...@php.net If there is no further comment, no, no news. Also there is a limit in the size of the command line arguments (platform-version dependent), so using very long cmd line is a bad idea, pipes or file based argument is a way better way to do such things. [2011-02-09 10:26:59] tyra3l at gmail dot com any update on this? Tyrael [2010-10-17 10:49:09] bouke at webatoom dot nl I ran into the same problem, but sleep(1) didn't work. I had to use sleep(2) on my machine (Win7 x64 on C2Q9450). [2010-09-24 04:45:37] cataphr...@php.net Strangely, it works if you sleep(1) after proc_open. [2010-09-23 13:36:35] mz dot evgeny at gmail dot com It will be more correct to say that it does write the whole string, but php.exe doesn't get the complete string for some reason. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52911 -- Edit this bug report at http://bugs.php.net/bug.php?id=52911edit=1
Req #54033 [Com]: add get_error_handler and get_exception handler
Edit report at http://bugs.php.net/bug.php?id=54033edit=1 ID: 54033 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:add get_error_handler and get_exception handler Status: Re-Opened Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.3.5 Block user comment: N Private report: N New Comment: the get_exception_handler is least important for me: I cannot come up with a situation, which couldn't be solved by set_exception_handler and restore_exception_handler, because the exception handler doesn't have something like the $error_types in the set_error_handler. but I think it would be more consistent if both the error and exception handler functions would provide that. Tyrael Previous Comments: [2011-02-17 01:04:00] tyra3l at gmail dot com of course it returns the callback. but: - you can't get it without overwriting - it doesn't return the error_types, hence you won't know on which error should you call the previous handler - if you would think, that maybe the restore_error_handler would come to the rescue(you set your error handler, in your error handler you catch everything, and restore the previous handler for the errors that isn't for you and and call the original error handler with trigger_error): you can only tigger E_USER_*. :( am I missing something? if not, please re-open the issue, because it isn't bogus. Tyrael [2011-02-17 00:50:53] ras...@php.net set_error_handler() already returns the previously set error handler, if any. [2011-02-17 00:44:58] tyra3l at gmail dot com Description: my co-worker had a problem with the Zend Framework Soap Server class: he was using trigger_error for handling the application level errors, and the ZF Soap Server class set his own error_handler, so my co-worker's error handler was swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you have an userspace error handler then every error type, which isn't observed will be discarded) I mentioned this on twitter (I wasn't really nice) http://twitter.com/#!/Tyr43l/status/22704699030 and Matthew Weier O'Phinney responded that they had to do this, because there was some quirks about the SoapServer or DomDocument class. so if they don't set their error_handler, they can't handle the error, if they do, they will overwrite any existing error_handler. if there would be a way, to get the current(previous) error handler, then they could have save the current/previous error handler (with the error type parameter!) and from their error handler, they could have call the applevel error handler callback. of course, some stackable mechanism, like the spl_autoload would be a more better approach but that would break BC, at least I couldn't figure out a way to do it without problems. I will ask Matthew to comment on this issue (what was the exact problem that forced them to set the error handler at the first place) -- Edit this bug report at http://bugs.php.net/bug.php?id=54033edit=1
Bug #51463 [ReO-Csd]: ErrorException thrown from error_handler not catchable in exception handler
Edit report at http://bugs.php.net/bug.php?id=51463edit=1 ID: 51463 User updated by:tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:ErrorException thrown from error_handler not catchable in exception handler -Status: Re-Opened +Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Windows Xp Sp3, Debian Lenny PHP Version:5.3.2 Block user comment: N Private report: N New Comment: I will try to reproduce the problem with a more clean test script, and create a new issue for that. Tyrael Previous Comments: [2010-05-05 21:24:40] tyra3l at gmail dot com obviously. closures was added with php 5.3 http://php.net/manual/en/functions.anonymous.php Tyrael [2010-05-05 20:15:14] whatrevolution at yahoo dot com OP's test code, result: ( ! ) Parse error: syntax error, unexpected T_FUNCTION, expecting ')' in /var/www/php_bugs/exception_in_error_handler.php on line 13 PHP Version 5.2.10-2ubuntu6.4 System Linux 2.6.31-20-generic x86_64 Build Date Jan 6 2010 22:36:47 Server API Apache 2.0 Handler PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 Debug Build no Thread Safety disabled Zend Memory Manager enabled Apache/2.2.12 (Ubuntu) [2010-04-02 15:19:15] tyra3l at gmail dot com Another weird thing that I observed: If I try to handle the fatal error from register shutdown function then the error_get_last() will return NULL if I throw the ErrorException from the error handler. If I don't try to convert exceptions from errors, then the error_get_last() will return the fatal error in the shutdown function. Or if I generate fatal error for example with new NonExistentClassName; then the error_handler doesn't get called (because this is a fatal error), but the shutdown function gets the fatal error with error_get_last() So it seems that there is some strange magic with this situation. Tyrael [2010-04-02 13:41:02] tyra3l at gmail dot com But the exception handler should be called after the error handler and before accessing the empty property which gives the fatal error, isn't it? I mean at first the interpreter tries to access the variable named $foo, then generates a E_NOTICE which is trapped by the error handler, which trows an Exception which never catched at all. [2010-04-02 13:35:54] tyra3l at gmail dot com shit, my mistake, $foo will be empty, so $this-$foo will be generating a fatal error, but before that, generate a warning about $foo is empty. :/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51463 -- Edit this bug report at http://bugs.php.net/bug.php?id=51463edit=1
Req #36636 [Com]: Fatal, compiler and related errors return a HTTP status code of 200.
Edit report at http://bugs.php.net/bug.php?id=36636edit=1 ID: 36636 Comment by: tyra3l at gmail dot com Reported by:jonnay at jonnay dot net Summary:Fatal, compiler and related errors return a HTTP status code of 200. Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Any PHP Version:5.1.2 Block user comment: N Private report: N New Comment: this is implemented yet imho. there is a bug with xdebug: http://bugs.php.net/bug.php?id=50921 Previous Comments: [2006-03-06 20:33:12] jonnay at jonnay dot net Description: When a script is executing, and an E_ERROR or an E_PARSE error occurs (and perhaps E_CORE_ERROR, E_COMPILE_ERROR), an HTTP status code of 500 should be sent (when possible), rather then a 200, because the server has in fact encountered an internal error, and everything is not actually OK. -- Edit this bug report at http://bugs.php.net/bug.php?id=36636edit=1
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at http://bugs.php.net/bug.php?id=32100edit=1
ID: 32100
Comment by: tyra3l at gmail dot com
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
+1 for adding the feature.
I'm a little bit disappointed that there are no comment from the php
core contributors on this issue except helly, and he didn't the first
which closed the, I could accept the fact, that this cannot be done by
technical reasons, but AFAIK it was rejected, because the core devs at
that time didn't used or understood the finally, so they said, that
nobody needs that.
http://marc.info/?l=php-internalsm=96773381231437w=2
times has changed, try doesn't leaks memory nowdays (or does it?),
people got smarter, machines faster, maybe we could reconsider this
feature, and reject it based on the current situation, not from a vague
discussion from 10 years ago.
Tyrael
Previous Comments:
[2011-02-17 14:14:33] hardyanto dot donny at gmail dot com
finally is very useful for using ADODB:
$db-StartTransaction();
try{
... any exception can occur here...
} finally {
$db-CompleteTrans();
}
Even there is exception occur in try block, the CompleteTrans() always
be
called.
[2010-12-10 23:22:17] btsai at vrwarp dot com
Wouldn't the argument against finally from Bjarne Stroustrup's C++ Style
and Technique FAQ
(http://www2.research.att.com/~bs/bs_faq2.html#finally) hold true?
Basically, most good uses of finally are used for deallocating
resources. Another way would simply be to design an object that
represents the resource that automatically deallocates itself via the
destructor.
[2010-12-10 16:08:56] marcus at lastcraft dot com
Hi...
The lack of finally causes us some crufty hard to debug code. The
comment about swallowing the source of the exception is not an academic
one - I've had grief over this.
As for exceptions being used for control flow - they are control flow,
that's the whole point. There is an antiquated argument from the C++ era
about this, mostly driven by outdated performance data. Exceptions are
not the same as errors, being more akin to a continuation when the usual
return path does not make sense.
Please, plase add finally to PHP as Java did to C++.
yours, Marcus
[2010-12-10 12:02:15] joshuaswift at gmail dot com
Please add a finally block for exception handling
[2010-10-03 07:58:34] matsubokkuri+php at gmail dot com
c891652 at bofthew dot com
I'm disappointed about this request is closed without critical reasons.
The first comment author doesn't understand OOP correctly. The code
cannot raise
exception to upper class.
The code would be following without finally statement.
// create temporary file
try{
// write to temporary file
}catch(ConnectionException $e){
// delete temporary file
}
// delete temporary file
The delete temporary file sentence would be duplicate.
I can write with finally as following without duplicate delete
temporary file.
// create temporary file
try{
// write to temporary file
}finally{
// delete temporary file
}
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=32100
--
Edit this bug report at http://bugs.php.net/bug.php?id=32100edit=1
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at http://bugs.php.net/bug.php?id=32100edit=1
ID: 32100
Comment by: tyra3l at gmail dot com
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
sorry, I screwed up part of my comment when editing:
and he didn't the first which closed the
and he didn't explained in his comment why is it rejected, aside the
fact that we (who?) dont't need it
Tyrael
Previous Comments:
[2011-02-17 16:54:06] tyra3l at gmail dot com
+1 for adding the feature.
I'm a little bit disappointed that there are no comment from the php
core contributors on this issue except helly, and he didn't the first
which closed the, I could accept the fact, that this cannot be done by
technical reasons, but AFAIK it was rejected, because the core devs at
that time didn't used or understood the finally, so they said, that
nobody needs that.
http://marc.info/?l=php-internalsm=96773381231437w=2
times has changed, try doesn't leaks memory nowdays (or does it?),
people got smarter, machines faster, maybe we could reconsider this
feature, and reject it based on the current situation, not from a vague
discussion from 10 years ago.
Tyrael
[2011-02-17 14:14:33] hardyanto dot donny at gmail dot com
finally is very useful for using ADODB:
$db-StartTransaction();
try{
... any exception can occur here...
} finally {
$db-CompleteTrans();
}
Even there is exception occur in try block, the CompleteTrans() always
be
called.
[2010-12-10 23:22:17] btsai at vrwarp dot com
Wouldn't the argument against finally from Bjarne Stroustrup's C++ Style
and Technique FAQ
(http://www2.research.att.com/~bs/bs_faq2.html#finally) hold true?
Basically, most good uses of finally are used for deallocating
resources. Another way would simply be to design an object that
represents the resource that automatically deallocates itself via the
destructor.
[2010-12-10 16:08:56] marcus at lastcraft dot com
Hi...
The lack of finally causes us some crufty hard to debug code. The
comment about swallowing the source of the exception is not an academic
one - I've had grief over this.
As for exceptions being used for control flow - they are control flow,
that's the whole point. There is an antiquated argument from the C++ era
about this, mostly driven by outdated performance data. Exceptions are
not the same as errors, being more akin to a continuation when the usual
return path does not make sense.
Please, plase add finally to PHP as Java did to C++.
yours, Marcus
[2010-12-10 12:02:15] joshuaswift at gmail dot com
Please add a finally block for exception handling
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=32100
--
Edit this bug report at http://bugs.php.net/bug.php?id=32100edit=1
[PHP-BUG] Req #54032 [NEW]: ability to to handle Class not found error
From: Operating system: PHP version: 5.3.5 Package: SPL related Bug Type: Feature/Change Request Bug description:ability to to handle Class not found error Description: currently you can throw an exception from the autoloader, hence if you can't find a class, your application can gracefully exists, instead of exiting via the class not found fatal error. my problem is, that I would like to use multiple autoloader (for example in a project which uses multiple component, or framework), but in this case, I can't throw an Exception from my autoloader, because maybe the other autoloaders could load the class. if I'm sure that I will register the last autoloader, the this isn't a problem(my last autoloader will throw the Exception on missing class), but maybe I have to load a component late of the exection. it would be cool, if I could somehow register a callback which will be called, when the spl autoload callbacks was executed, but the class couldn't be loaded of course, from this callback, I cannot continue the normal execution flow, however I can log the error, and let the callback return and get the class not found fatal error, or throw an Exception, and handle/log the error from a higher level. -- Edit bug report at http://bugs.php.net/bug.php?id=54032edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54032r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54032r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54032r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54032r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54032r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54032r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54032r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54032r=needscript Try newer version: http://bugs.php.net/fix.php?id=54032r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54032r=support Expected behavior: http://bugs.php.net/fix.php?id=54032r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54032r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54032r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54032r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54032r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54032r=dst IIS Stability: http://bugs.php.net/fix.php?id=54032r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54032r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54032r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54032r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54032r=mysqlcfg
Req #54032 [Com]: ability to to handle Class not found error
Edit report at http://bugs.php.net/bug.php?id=54032edit=1 ID: 54032 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:ability to to handle Class not found error Status: Open Type: Feature/Change Request Package:SPL related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: *exists - exit *exection - execution * spl autoload callbacks was executed - spl autoload callbacks was executed without finding the class * I cannot continue the normal execution flow - I couldn't continue the normal execution flow * from a higher level - at a higher level sorry, its getting late, and my english skill degrades with sleep deprivation Previous Comments: [2011-02-17 00:11:01] tyra3l at gmail dot com Description: currently you can throw an exception from the autoloader, hence if you can't find a class, your application can gracefully exists, instead of exiting via the class not found fatal error. my problem is, that I would like to use multiple autoloader (for example in a project which uses multiple component, or framework), but in this case, I can't throw an Exception from my autoloader, because maybe the other autoloaders could load the class. if I'm sure that I will register the last autoloader, the this isn't a problem(my last autoloader will throw the Exception on missing class), but maybe I have to load a component late of the exection. it would be cool, if I could somehow register a callback which will be called, when the spl autoload callbacks was executed, but the class couldn't be loaded of course, from this callback, I cannot continue the normal execution flow, however I can log the error, and let the callback return and get the class not found fatal error, or throw an Exception, and handle/log the error from a higher level. -- Edit this bug report at http://bugs.php.net/bug.php?id=54032edit=1
[PHP-BUG] Req #54033 [NEW]: add get_error_handler and get_exception handler
From: Operating system: PHP version: 5.3.5 Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:add get_error_handler and get_exception handler Description: my co-worker had a problem with the Zend Framework Soap Server class: he was using trigger_error for handling the application level errors, and the ZF Soap Server class set his own error_handler, so my co-worker's error handler was swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you have an userspace error handler then every error type, which isn't observed will be discarded) I mentioned this on twitter (I wasn't really nice) http://twitter.com/#!/Tyr43l/status/22704699030 and Matthew Weier O'Phinney responded that they had to do this, because there was some quirks about the SoapServer or DomDocument class. so if they don't set their error_handler, they can't handle the error, if they do, they will overwrite any existing error_handler. if there would be a way, to get the current(previous) error handler, then they could have save the current/previous error handler (with the error type parameter!) and from their error handler, they could have call the applevel error handler callback. of course, some stackable mechanism, like the spl_autoload would be a more better approach but that would break BC, at least I couldn't figure out a way to do it without problems. I will ask Matthew to comment on this issue (what was the exact problem that forced them to set the error handler at the first place) -- Edit bug report at http://bugs.php.net/bug.php?id=54033edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54033r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54033r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54033r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54033r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54033r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54033r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54033r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54033r=needscript Try newer version: http://bugs.php.net/fix.php?id=54033r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54033r=support Expected behavior: http://bugs.php.net/fix.php?id=54033r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54033r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54033r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54033r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54033r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54033r=dst IIS Stability: http://bugs.php.net/fix.php?id=54033r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54033r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54033r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54033r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54033r=mysqlcfg
Req #54033 [Com]: add get_error_handler and get_exception handler
Edit report at http://bugs.php.net/bug.php?id=54033edit=1 ID: 54033 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:add get_error_handler and get_exception handler Status: Bogus Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.3.5 Block user comment: N Private report: N New Comment: of course it returns the callback. but: - you can't get it without overwriting - it doesn't return the error_types, hence you won't know on which error should you call the previous handler - if you would think, that maybe the restore_error_handler would come to the rescue(you set your error handler, in your error handler you catch everything, and restore the previous handler for the errors that isn't for you and and call the original error handler with trigger_error): you can only tigger E_USER_*. :( am I missing something? if not, please re-open the issue, because it isn't bogus. Tyrael Previous Comments: [2011-02-17 00:50:53] ras...@php.net set_error_handler() already returns the previously set error handler, if any. [2011-02-17 00:44:58] tyra3l at gmail dot com Description: my co-worker had a problem with the Zend Framework Soap Server class: he was using trigger_error for handling the application level errors, and the ZF Soap Server class set his own error_handler, so my co-worker's error handler was swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you have an userspace error handler then every error type, which isn't observed will be discarded) I mentioned this on twitter (I wasn't really nice) http://twitter.com/#!/Tyr43l/status/22704699030 and Matthew Weier O'Phinney responded that they had to do this, because there was some quirks about the SoapServer or DomDocument class. so if they don't set their error_handler, they can't handle the error, if they do, they will overwrite any existing error_handler. if there would be a way, to get the current(previous) error handler, then they could have save the current/previous error handler (with the error type parameter!) and from their error handler, they could have call the applevel error handler callback. of course, some stackable mechanism, like the spl_autoload would be a more better approach but that would break BC, at least I couldn't figure out a way to do it without problems. I will ask Matthew to comment on this issue (what was the exact problem that forced them to set the error handler at the first place) -- Edit this bug report at http://bugs.php.net/bug.php?id=54033edit=1
Bug #52911 [Com]: fwrite doesn't write long strings to a php stream
Edit report at http://bugs.php.net/bug.php?id=52911edit=1
ID: 52911
Comment by: tyra3l at gmail dot com
Reported by:mz dot evgeny at gmail dot com
Summary:fwrite doesn't write long strings to a php stream
Status: Verified
Type: Bug
Package:*General Issues
Operating System: Windows
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
any update on this?
Tyrael
Previous Comments:
[2010-10-17 10:49:09] bouke at webatoom dot nl
I ran into the same problem, but sleep(1) didn't work. I had to use
sleep(2)
on my machine (Win7 x64 on C2Q9450).
[2010-09-24 04:45:37] cataphr...@php.net
Strangely, it works if you sleep(1) after proc_open.
[2010-09-23 13:36:35] mz dot evgeny at gmail dot com
It will be more correct to say that it does write the whole string, but
php.exe doesn't get the complete string for some reason.
[2010-09-23 13:18:34] mz dot evgeny at gmail dot com
Description:
fwrite doesn't write long strings to a stream.
When i try to open a php process and write a long-script to it, i get a
parse error.
Test script:
---
$descriptorSpec = array(
0 = array('pipe', 'r'),
1 = array('pipe', 'w'),
2 = array('pipe', 'w')
);
$process = proc_open(php.exe, $descriptorSpec, $pipes);
var_dump(fwrite($pipes[0], ?php ' . str_repeat(1, 8500) . ';
?));
fclose($pipes[0]);
$stdout = stream_get_contents($pipes[1]);
fclose($pipes[1]);
proc_close($process);
print_r($stdout);
Expected result:
int 8513
No error.
Actual result:
--
int 8513
Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE in - on
line 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=52911edit=1
Req #47871 [Com]: PHPIniScanDir directive for apache allows scanning for extension ini files
Edit report at http://bugs.php.net/bug.php?id=47871edit=1 ID: 47871 Comment by: tyra3l at gmail dot com Reported by:sriram dot natarajan at gmail dot com Summary:PHPIniScanDir directive for apache allows scanning for extension ini files Status: Assigned Type: Feature/Change Request Package:PHP options/info functions Operating System: unix and linux PHP Version:5.3.0RC1 Assigned To:dsp Block user comment: N Private report: N New Comment: poke Tyrael Previous Comments: [2009-05-04 18:19:16] sriram dot natarajan at gmail dot com how does this work ? will this need to be ported all the sapi's currently supported by PHP or can it be on a user request basis ? for, example - i can provide the patch for ISAPI ? will that help ? For NSAPI, lot of things are broke as is. for example, php ini dir itself does not work with recent version of sun web server. I plan to file a separate bug for NSAPI and can provide a separate patch to address this issue for nsapi. I don't have lot of experience with thttpd or roxen. Does this patch need to be ported to those SAPI's as well ? are these SAPI's actively used by the community ? [2009-05-04 15:12:54] paj...@php.net David, what's the status about this one? Should it not be for all SAPI instead? [2009-04-29 00:01:04] d...@php.net I think that's a good one. I assign it to me so that we don't forget about that one. [2009-04-02 02:47:47] sriram dot natarajan at gmail dot com hi here is the patch to address this issue http://cr.opensolaris.org/~sn123202/php53-47871.patch http://cr.opensolaris.org/~sn123202/php52-47871.patch let me know with your comments.. [2009-04-02 02:28:41] sriram dot natarajan at gmail dot com Description: Provide PHPIniScanDir directive similar to PHPIniDir for apache. this directive can perform the functionality of PHP_INI_SCAN_DIR environment variable. for more information on what PHP_INI_SCAN_DIR, please refer to bug http://bugs.php.net/bug.php?id=45114 Expected result: PHPIniScanDir directive should be accepted and php should load extension specific ini files from this location -- Edit this bug report at http://bugs.php.net/bug.php?id=47871edit=1
Req #47871 [Com]: PHPIniScanDir directive for apache allows scanning for extension ini files
Edit report at http://bugs.php.net/bug.php?id=47871edit=1 ID: 47871 Comment by: tyra3l at gmail dot com Reported by:sriram dot natarajan at gmail dot com Summary:PHPIniScanDir directive for apache allows scanning for extension ini files Status: Assigned Type: Feature/Change Request Package:PHP options/info functions Operating System: unix and linux PHP Version:5.3.0RC1 Assigned To:dsp Block user comment: N Private report: N New Comment: for the record: passing PHP_INI_SCAN_DIR through SetEnv from apache confid doesnt work: the environment variable will be there(at least by phpinfo()), but the Scan this dir for additional .ini files will be empty. on the other hand, if you set/export an environment variable in the shell where you start the apache afterwards, that does work. so for now, one can set this option runtime, but it would be a nicer solution, if the apache SetEnv would work, or if the patch would be merged, so we would have an apache directive called PHP_INI_SCAN_DIR. Tyrael Previous Comments: [2011-02-02 22:04:21] tyra3l at gmail dot com poke Tyrael [2009-05-04 18:19:16] sriram dot natarajan at gmail dot com how does this work ? will this need to be ported all the sapi's currently supported by PHP or can it be on a user request basis ? for, example - i can provide the patch for ISAPI ? will that help ? For NSAPI, lot of things are broke as is. for example, php ini dir itself does not work with recent version of sun web server. I plan to file a separate bug for NSAPI and can provide a separate patch to address this issue for nsapi. I don't have lot of experience with thttpd or roxen. Does this patch need to be ported to those SAPI's as well ? are these SAPI's actively used by the community ? [2009-05-04 15:12:54] paj...@php.net David, what's the status about this one? Should it not be for all SAPI instead? [2009-04-29 00:01:04] d...@php.net I think that's a good one. I assign it to me so that we don't forget about that one. [2009-04-02 02:47:47] sriram dot natarajan at gmail dot com hi here is the patch to address this issue http://cr.opensolaris.org/~sn123202/php53-47871.patch http://cr.opensolaris.org/~sn123202/php52-47871.patch let me know with your comments.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=47871 -- Edit this bug report at http://bugs.php.net/bug.php?id=47871edit=1
Bug #53821 [Com]: go-pear installs PEAR 1.9.0 instead of 1.9.1
Edit report at http://bugs.php.net/bug.php?id=53821edit=1 ID: 53821 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:go-pear installs PEAR 1.9.0 instead of 1.9.1 Status: Assigned Type: Bug Package:Windows Installer Operating System: Windows PHP Version:5.3.5 Assigned To:pajoye Block user comment: N Private report: N New Comment: So this will be fixed in 5.3.6? Judging from the PEAR repository, it seems, that the 1.9.1 was tagged 7 month ago. What was the reason that the last 2 release was shipped with the 1.9.0? Do you update this manually? Maybe this could be automated in the build/release process, so it won't be forgotten. Tyrael Previous Comments: [2011-01-24 01:07:39] paj...@php.net We take the one available at http://pear.php.net/go-pear.phar by the time of the 1st RC for a given release. Next release(s) will have the new ones, or the snapshots for the impatient. In the mean time, simply replace the go-pear.phar in the pear directory before running go-pear and it should work well. [2011-01-23 17:53:15] tyra3l at gmail dot com I don't think we need any more info than already present, it's clear that the go- pear.phar in the latest windows builds contains the 1.9.0 pear, and other old PEAR libs, as I mentioned in the bugreport. Tyrael [2011-01-23 17:42:48] bulk at janoszen dot hu I tried to extract the URL's the PEAR installer accesses and came up with nothing. My installation log can be found here: http://pastebin.com/4yMJQiQP [2011-01-23 17:09:48] bulk at janoszen dot hu tyra3l at gmail dot com: by not affected I mean it will not be reproducible on a standard install 32 bit platform. Sorry, wrong wording. [2011-01-23 13:11:39] tyra3l at gmail dot com What do you mean by not affected? AFAIK the installed PEAR version has nothing to do with the version of the OS(be 32 or 64 bit), so this bug affects all windows versions. if you are talking about the referenced PEAR bug ( http://pear.php.net/bugs/bug.php?id=16644 ) then I think thats not true also. the source of the problem is the incorrect escaping of the shell arguments, which isn't related to the windows version, the only thing that makes the bug appear is that you have spaces in your installation path, or not. feel free to correct me though. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53821 -- Edit this bug report at http://bugs.php.net/bug.php?id=53821edit=1
[PHP-BUG] Bug #53821 [NEW]: go-pear installs PEAR 1.9.0 instead of 1.9.1
From: Operating system: Windows PHP version: 5.3.5 Package: Windows Installer Bug Type: Bug Bug description:go-pear installs PEAR 1.9.0 instead of 1.9.1 Description: yesterday I had a discussion with my friend on twitter, and he said, that the pear installer is broken on windows 7. we tracked down, that his problem is a known bug and fixed in PEAR 1.9.1, caused by the installation path containing spaces. http://pear.php.net/bugs/bug.php?id=16644 so it shouldn't happen right? but it does, because the go-pear shipped with the latest windows binaries is old, and tries to install the 1.9.0 version. please update that to 1.9.1 there are other pear packages that needs updated, so maybe it would be a good idea to bump them also: Archive_Tar-1.3.3 vs Archive_Tar-1.3.7 Console_Getopt-1.2.3 vs Console_Getopt-1.3.0 Structures_Graph-1.0.2 vs Structures_Graph-1.0.4 on the long term, maybe it would be a good idea, to modify the installer to fetch the latest versions on-the-fly as part of the installation process, for now, maybe we could add a step for upgrading(or telling the people to upgrade) the packages to the go-pear.bat installation process. Test script: --- fetch the windows binary, run go-pear.bat and after the successful install, check pear version, pear list Expected result: should list the latest versions of the installed packages Actual result: -- now it lists the old packages -- Edit bug report at http://bugs.php.net/bug.php?id=53821edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53821r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53821r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53821r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53821r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53821r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53821r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53821r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53821r=needscript Try newer version: http://bugs.php.net/fix.php?id=53821r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53821r=support Expected behavior: http://bugs.php.net/fix.php?id=53821r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53821r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53821r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53821r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53821r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53821r=dst IIS Stability: http://bugs.php.net/fix.php?id=53821r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53821r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53821r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53821r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53821r=mysqlcfg
Bug #53821 [Com]: go-pear installs PEAR 1.9.0 instead of 1.9.1
Edit report at http://bugs.php.net/bug.php?id=53821edit=1 ID: 53821 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:go-pear installs PEAR 1.9.0 instead of 1.9.1 Status: Open Type: Bug Package:Windows Installer Operating System: Windows PHP Version:5.3.5 Block user comment: N Private report: N New Comment: What do you mean by not affected? AFAIK the installed PEAR version has nothing to do with the version of the OS(be 32 or 64 bit), so this bug affects all windows versions. if you are talking about the referenced PEAR bug ( http://pear.php.net/bugs/bug.php?id=16644 ) then I think thats not true also. the source of the problem is the incorrect escaping of the shell arguments, which isn't related to the windows version, the only thing that makes the bug appear is that you have spaces in your installation path, or not. feel free to correct me though. Previous Comments: [2011-01-23 12:45:42] bulk at janoszen dot hu Please note, that this bug only surfaces on 64 bit Windows versions, 32 bit versions are not affected. [2011-01-23 12:38:03] tyra3l at gmail dot com Description: yesterday I had a discussion with my friend on twitter, and he said, that the pear installer is broken on windows 7. we tracked down, that his problem is a known bug and fixed in PEAR 1.9.1, caused by the installation path containing spaces. http://pear.php.net/bugs/bug.php?id=16644 so it shouldn't happen right? but it does, because the go-pear shipped with the latest windows binaries is old, and tries to install the 1.9.0 version. please update that to 1.9.1 there are other pear packages that needs updated, so maybe it would be a good idea to bump them also: Archive_Tar-1.3.3 vs Archive_Tar-1.3.7 Console_Getopt-1.2.3 vs Console_Getopt-1.3.0 Structures_Graph-1.0.2 vs Structures_Graph-1.0.4 on the long term, maybe it would be a good idea, to modify the installer to fetch the latest versions on-the-fly as part of the installation process, for now, maybe we could add a step for upgrading(or telling the people to upgrade) the packages to the go-pear.bat installation process. Test script: --- fetch the windows binary, run go-pear.bat and after the successful install, check pear version, pear list Expected result: should list the latest versions of the installed packages Actual result: -- now it lists the old packages -- Edit this bug report at http://bugs.php.net/bug.php?id=53821edit=1
Bug #53821 [Com]: go-pear installs PEAR 1.9.0 instead of 1.9.1
Edit report at http://bugs.php.net/bug.php?id=53821edit=1 ID: 53821 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:go-pear installs PEAR 1.9.0 instead of 1.9.1 Status: Open Type: Bug Package:Windows Installer Operating System: Windows PHP Version:5.3.5 Block user comment: N Private report: N New Comment: I don't think we need any more info than already present, it's clear that the go- pear.phar in the latest windows builds contains the 1.9.0 pear, and other old PEAR libs, as I mentioned in the bugreport. Tyrael Previous Comments: [2011-01-23 17:42:48] bulk at janoszen dot hu I tried to extract the URL's the PEAR installer accesses and came up with nothing. My installation log can be found here: http://pastebin.com/4yMJQiQP [2011-01-23 17:09:48] bulk at janoszen dot hu tyra3l at gmail dot com: by not affected I mean it will not be reproducible on a standard install 32 bit platform. Sorry, wrong wording. [2011-01-23 13:11:39] tyra3l at gmail dot com What do you mean by not affected? AFAIK the installed PEAR version has nothing to do with the version of the OS(be 32 or 64 bit), so this bug affects all windows versions. if you are talking about the referenced PEAR bug ( http://pear.php.net/bugs/bug.php?id=16644 ) then I think thats not true also. the source of the problem is the incorrect escaping of the shell arguments, which isn't related to the windows version, the only thing that makes the bug appear is that you have spaces in your installation path, or not. feel free to correct me though. [2011-01-23 12:45:42] bulk at janoszen dot hu Please note, that this bug only surfaces on 64 bit Windows versions, 32 bit versions are not affected. [2011-01-23 12:38:03] tyra3l at gmail dot com Description: yesterday I had a discussion with my friend on twitter, and he said, that the pear installer is broken on windows 7. we tracked down, that his problem is a known bug and fixed in PEAR 1.9.1, caused by the installation path containing spaces. http://pear.php.net/bugs/bug.php?id=16644 so it shouldn't happen right? but it does, because the go-pear shipped with the latest windows binaries is old, and tries to install the 1.9.0 version. please update that to 1.9.1 there are other pear packages that needs updated, so maybe it would be a good idea to bump them also: Archive_Tar-1.3.3 vs Archive_Tar-1.3.7 Console_Getopt-1.2.3 vs Console_Getopt-1.3.0 Structures_Graph-1.0.2 vs Structures_Graph-1.0.4 on the long term, maybe it would be a good idea, to modify the installer to fetch the latest versions on-the-fly as part of the installation process, for now, maybe we could add a step for upgrading(or telling the people to upgrade) the packages to the go-pear.bat installation process. Test script: --- fetch the windows binary, run go-pear.bat and after the successful install, check pear version, pear list Expected result: should list the latest versions of the installed packages Actual result: -- now it lists the old packages -- Edit this bug report at http://bugs.php.net/bug.php?id=53821edit=1
Bug #53632 [Com]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632edit=1 ID: 53632 Comment by: tyra3l at gmail dot com Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Closed Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:scottmac Block user comment: N Private report: N New Comment: Just for the record, because some of my friends missed this: max_execution_time/set_time_limit cannot help you with this problem, because it's only gets checked between two userland instructions, hence this won't happen in this case. Tyrael Previous Comments: [2011-01-05 14:35:27] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307120 Log: Merge rev. 307097 Add test for bug #53632 (scottmac) [2011-01-05 14:32:29] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307119 Log: Merge rev. 307095 - Fix bug #53632 with x87 fpu (scottmac) [2011-01-05 10:28:35] zdv2010 at gmail dot com I have this problem on PHP-5.2.14 on Windows XP SP3 C:\Documents and Settings\userphp -v PHP 5.2.14 (cli) (built: Jul 21 2010 18:43:55) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies [2011-01-05 09:50:21] paj...@php.net Seems that the commit did not make it here: Fix: http://svn.php.net/viewvc?view=revisionrevision=307095 Test case: http://svn.php.net/viewvc?view=revisionrevision=307097 [2011-01-05 00:47:43] paj...@php.net My bad, forgot to revert a change in my previous attempt to fix this issue. Fresh co build works, tests pass. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632edit=1
Bug #53632 [Com]: PHP hangs on numeric value 2.2250738585072011e-308
Edit report at http://bugs.php.net/bug.php?id=53632edit=1 ID: 53632 Comment by: tyra3l at gmail dot com Reported by:exploringbinary at gmail dot com Summary:PHP hangs on numeric value 2.2250738585072011e-308 Status: Closed Type: Bug Package:Math related PHP Version:5.3.4 Assigned To:scottmac Block user comment: N Private report: N New Comment: btw. 5.2 support officially ended. are there any chances that this bug will be fixed in 5.2, or this will be the first obstacle which will force the people out there to upgrade to 5.3? Tyrael Previous Comments: [2011-01-05 15:13:54] tyra3l at gmail dot com Just for the record, because some of my friends missed this: max_execution_time/set_time_limit cannot help you with this problem, because it's only gets checked between two userland instructions, hence this won't happen in this case. Tyrael [2011-01-05 14:35:27] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307120 Log: Merge rev. 307097 Add test for bug #53632 (scottmac) [2011-01-05 14:32:29] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307119 Log: Merge rev. 307095 - Fix bug #53632 with x87 fpu (scottmac) [2011-01-05 10:28:35] zdv2010 at gmail dot com I have this problem on PHP-5.2.14 on Windows XP SP3 C:\Documents and Settings\userphp -v PHP 5.2.14 (cli) (built: Jul 21 2010 18:43:55) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies [2011-01-05 09:50:21] paj...@php.net Seems that the commit did not make it here: Fix: http://svn.php.net/viewvc?view=revisionrevision=307095 Test case: http://svn.php.net/viewvc?view=revisionrevision=307097 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53632 -- Edit this bug report at http://bugs.php.net/bug.php?id=53632edit=1
Bug #53227 [Fbk-Opn]: PHP Warning: mysql_pconnect(): MySQL server has gone away
Edit report at http://bugs.php.net/bug.php?id=53227edit=1 ID: 53227 User updated by:tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:PHP Warning: mysql_pconnect(): MySQL server has gone away -Status: Feedback +Status: Open Type: Bug Package:MySQL related PHP Version:5.3.3 Block user comment: N Private report: N New Comment: mysqlnd Tyrael Previous Comments: [2010-12-20 14:22:52] and...@php.net do you use libmysql or mysqlnd? [2010-11-02 12:13:04] tyra3l at gmail dot com Description: On of my co-worker experienced, that some of the mysql_pconnect calls are returning this error. The exact same symptoms are described in the manual: http://php.net/manual/en/function.mysql-pconnect.php#99380 the code which produce this was working fine before migrating to 5.3 Test script: --- ?php mysql_pconnect(); Expected result: successful connection every time Actual result: -- sometimes we get the PHP warning, and we had to retry the connection -- Edit this bug report at http://bugs.php.net/bug.php?id=53227edit=1
Req #12802 [Com]: gethostbyname/gethostbyaddr timeout
Edit report at http://bugs.php.net/bug.php?id=12802edit=1 ID: 12802 Comment by: tyra3l at gmail dot com Reported by:cheapsalsa at yahoo dot com Summary:gethostbyname/gethostbyaddr timeout Status: Open Type: Feature/Change Request Package:*General Issues Operating System: Linux (N/A) PHP Version:4.0CVS-2001-08-16 Block user comment: N Private report: N New Comment: maybe we could use some non-blocking dns library? http://c-ares.haxx.se/ Tyrael Previous Comments: [2010-11-19 00:05:31] paj...@php.net For the record, it is not possible to do it in PHP. These functions are implemented by the operating systems. Without creating a thread for the get* hosts, we won't have any control on the timeout. [2010-03-04 16:34:30] tyra3l at gmail dot com bump [2009-03-04 19:19:12] adifranco at tagged dot com Any intent to fix this? This kind of indeterminism is very crippling to trying to use these functions in a feature that interacts with the user. [2003-08-10 22:54:12] grimtraffic at hotmail dot com To be honest, no timeout has really made it hard to log users. There is no point of logging IP's because they change too often for dial-up users, and with my page timing out every third time someone goes to it, I now have troubles. By the way, 2 out of 3 who use gethostbyaddr have an issue with it timing out constantly. [2003-02-05 06:19:54] sergi at millorsoft dot es Is this bug still open? I think it's a really important bug and can cause very long retards when the DNS lookup doesn't respond or some DNS server is unreacheable. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=12802 -- Edit this bug report at http://bugs.php.net/bug.php?id=12802edit=1
Req #12802 [Com]: gethostbyname/gethostbyaddr timeout
Edit report at http://bugs.php.net/bug.php?id=12802edit=1 ID: 12802 Comment by: tyra3l at gmail dot com Reported by:cheapsalsa at yahoo dot com Summary:gethostbyname/gethostbyaddr timeout Status: Assigned Type: Feature/Change Request Package:*General Issues PHP Version:4.0CVS-2001-08-16 Assigned To:pajoye Block user comment: N Private report: N New Comment: can I access that implementation from userspace right now? if there is a way, then it's fine for me as is, but I wouldn't dare to change the current implementation of those functions. so maybe the best would be to add new userspace functions for the async behaviour. Tyrael Previous Comments: [2010-11-19 01:07:41] paj...@php.net We have an implementation, only a matter of using it instead of get*. I have some patch for that, adding some features for the DNS APIs. It should be easy to modify this function while being at it. [2010-11-19 00:53:25] tyra3l at gmail dot com maybe we could use some non-blocking dns library? http://c-ares.haxx.se/ Tyrael [2010-11-19 00:05:31] paj...@php.net For the record, it is not possible to do it in PHP. These functions are implemented by the operating systems. Without creating a thread for the get* hosts, we won't have any control on the timeout. [2010-03-04 16:34:30] tyra3l at gmail dot com bump [2009-03-04 19:19:12] adifranco at tagged dot com Any intent to fix this? This kind of indeterminism is very crippling to trying to use these functions in a feature that interacts with the user. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=12802 -- Edit this bug report at http://bugs.php.net/bug.php?id=12802edit=1
[PHP-BUG] Bug #53227 [NEW]: PHP Warning: mysql_pconnect(): MySQL server has gone away
From: Operating system: PHP version: 5.3.3 Package: MySQL related Bug Type: Bug Bug description:PHP Warning: mysql_pconnect(): MySQL server has gone away Description: On of my co-worker experienced, that some of the mysql_pconnect calls are returning this error. The exact same symptoms are described in the manual: http://php.net/manual/en/function.mysql-pconnect.php#99380 the code which produce this was working fine before migrating to 5.3 Test script: --- ?php mysql_pconnect(); Expected result: successful connection every time Actual result: -- sometimes we get the PHP warning, and we had to retry the connection -- Edit bug report at http://bugs.php.net/bug.php?id=53227edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53227r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53227r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53227r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53227r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53227r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53227r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53227r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53227r=needscript Try newer version: http://bugs.php.net/fix.php?id=53227r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53227r=support Expected behavior: http://bugs.php.net/fix.php?id=53227r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53227r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53227r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53227r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53227r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53227r=dst IIS Stability: http://bugs.php.net/fix.php?id=53227r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53227r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53227r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53227r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53227r=mysqlcfg
Bug #50921 [Com]: '200 OK' HTTP status despite PHP error
Edit report at http://bugs.php.net/bug.php?id=50921edit=1
ID: 50921
Comment by: tyra3l at gmail dot com
Reported by:phpbug at starurl dot com
Summary:'200 OK' HTTP status despite PHP error
Status: Bogus
Type: Bug
Package:HTTP related
Operating System: *
PHP Version:5.2.12
Block user comment: N
New Comment:
I can reproduce the problem.
I found out, that if I enable xdebug, then I get header 200, if I
disable it, then
it's 500.
Will report it to Derick.
Tyrael
Previous Comments:
[2010-03-12 08:37:24] anzenews at volja dot net
I am also having huge problems with this - haproxy health checks do not
work reliably because of this bug. Please consider reopening it - it is
not bogus.
PHP doesn't return HTTP error code, even if display_errors is set to 0.
One example:
?
ini_set('display_errors',0);
this_function_does_not_exist();
echo ok;
?
This returns an empty page with status code 200:
-
HTTP/1.1 200 OK
DateFri, 12 Mar 2010 07:27:15 GMT
Server Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny6 with Suhosin-Patch
X-Powered-ByPHP/5.2.6-1+lenny6
VaryAccept-Encoding
Content-Encodinggzip
Content-Length 20
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Content-Typetext/html
-
Content-Length is 20, probably because of gzip? There are no spaces
around PHP block in source code.
I have checked phpinfo() and display_errors is set to Off, so there is
no error there. Also, I have tried setting it in php.ini - no change.
Another problem: parse errors are also not handled correctly (even if
display_errors is set to 0 in php.ini). See previous poster's example.
Thanks!
[2010-02-03 19:03:56] der...@php.net
The reason why display errors needs to be turned of, is because
displayed errors generate output, and output causes the headers to be
send out. I'm afraid we can't do much about this.
[2010-02-03 18:01:37] phpbug at starurl dot com
Thank you for the swift response Jani.
I can confirm that the 500 status code works for the following (runtime
error):
?
ini_set('display_errors', 0);
$x = y();
?
But fails for parse errors (because the disply_errors line doesn't get
executed):
?
ini_set('display_errors', 0);
x = y;
?
Firstly, is this dependency really necessary? Just because we have
'display_errors' enabled doesn't mean we want fatal errors to go
unlogged and unnoticed because a 200 OK status is incorrectly
returned.
Secondly, the majority of PHP developers out there use shared hosting,
on which 'display_errors' is normally true and is impossible to change
globally - are we saying they're stuck with incorrect HTTP status codes
when parse errors occur?
The restriction that headers must not already have been sent is of
course understandable as it is unavoidable. Not overriding an explicitly
set HTTP status code also makes sense.
But why not set the status code as 500 Internal Server Error when any
fatal parse/runtime error occurs, regardless of the value of
'display_errors'? This would be consistent with the HTTP spec, which
recommends a 5XX response if an error occurs, and is followed by just
about every other web server language out there (e.g., ASP, .NET).
Many thanks, BJ
[2010-02-03 10:06:27] j...@php.net
It does happen. It requires that:
1) display_errors = off
2) No headers have been sent yet by the time the error happens
3) Status is 200 at that time.
[2010-02-03 04:23:42] phpbug at starurl dot com
Description:
My host runs PHP v5.2.12 (confirmed via phpversion) on IIS6 (Windows
Server, unknown version). When a PHP error occurs (parse error, runtime
error, etc), a 200 OK HTTP status is returned, instead of the correct
500 Internal Server Error.
This is despite claims in the change history for v5.2.4 that this issue
was fixed: Changed error handler to send HTTP 500 instead of blank
page on PHP errors. (Dmitry, Andrei Nigmatulin). This doesn't appear to
be the case on IIS6 (monitored remotely via HTTP Spy).
Reproduce code:
---
?
x = y; // cause parse error
?
Expected result:
Parse error mesage and 500 Internal Server Error HTTP status code.
Actual result:
--
Parse error mesage and 200 OK HTTP status code
--
Edit this bug report at http://bugs.php.net/bug.php?id=50921edit=1
Bug #50921 [Com]: '200 OK' HTTP status despite PHP error
Edit report at http://bugs.php.net/bug.php?id=50921edit=1
ID: 50921
Comment by: tyra3l at gmail dot com
Reported by:phpbug at starurl dot com
Summary:'200 OK' HTTP status despite PHP error
Status: Bogus
Type: Bug
Package:HTTP related
Operating System: *
PHP Version:5.2.12
Block user comment: N
New Comment:
It's seems that this is a known bug in the xdebug, see:
http://bugs.xdebug.org/view.php?id=587
but couldn't fix it without making some changes in php itself:
Before I can address this, there need to be some changes in PHP itself.
It
doesn't expose some required information to extensions yet that I will
need.
I hope this get fixed soon.
Tyrael
Previous Comments:
[2010-08-12 15:35:41] tyra3l at gmail dot com
I can reproduce the problem.
I found out, that if I enable xdebug, then I get header 200, if I
disable it, then
it's 500.
Will report it to Derick.
Tyrael
[2010-03-12 08:37:24] anzenews at volja dot net
I am also having huge problems with this - haproxy health checks do not
work reliably because of this bug. Please consider reopening it - it is
not bogus.
PHP doesn't return HTTP error code, even if display_errors is set to 0.
One example:
?
ini_set('display_errors',0);
this_function_does_not_exist();
echo ok;
?
This returns an empty page with status code 200:
-
HTTP/1.1 200 OK
DateFri, 12 Mar 2010 07:27:15 GMT
Server Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny6 with Suhosin-Patch
X-Powered-ByPHP/5.2.6-1+lenny6
VaryAccept-Encoding
Content-Encodinggzip
Content-Length 20
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Content-Typetext/html
-
Content-Length is 20, probably because of gzip? There are no spaces
around PHP block in source code.
I have checked phpinfo() and display_errors is set to Off, so there is
no error there. Also, I have tried setting it in php.ini - no change.
Another problem: parse errors are also not handled correctly (even if
display_errors is set to 0 in php.ini). See previous poster's example.
Thanks!
[2010-02-03 19:03:56] der...@php.net
The reason why display errors needs to be turned of, is because
displayed errors generate output, and output causes the headers to be
send out. I'm afraid we can't do much about this.
[2010-02-03 18:01:37] phpbug at starurl dot com
Thank you for the swift response Jani.
I can confirm that the 500 status code works for the following (runtime
error):
?
ini_set('display_errors', 0);
$x = y();
?
But fails for parse errors (because the disply_errors line doesn't get
executed):
?
ini_set('display_errors', 0);
x = y;
?
Firstly, is this dependency really necessary? Just because we have
'display_errors' enabled doesn't mean we want fatal errors to go
unlogged and unnoticed because a 200 OK status is incorrectly
returned.
Secondly, the majority of PHP developers out there use shared hosting,
on which 'display_errors' is normally true and is impossible to change
globally - are we saying they're stuck with incorrect HTTP status codes
when parse errors occur?
The restriction that headers must not already have been sent is of
course understandable as it is unavoidable. Not overriding an explicitly
set HTTP status code also makes sense.
But why not set the status code as 500 Internal Server Error when any
fatal parse/runtime error occurs, regardless of the value of
'display_errors'? This would be consistent with the HTTP spec, which
recommends a 5XX response if an error occurs, and is followed by just
about every other web server language out there (e.g., ASP, .NET).
Many thanks, BJ
[2010-02-03 10:06:27] j...@php.net
It does happen. It requires that:
1) display_errors = off
2) No headers have been sent yet by the time the error happens
3) Status is 200 at that time.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=50921
--
Edit this bug report at http://bugs.php.net/bug.php?id=50921edit=1
[PHP-BUG] Bug #52508 [NEW]: newline problem with parse_ini_file+INI_SCANNER_RAW
From: Operating system: linux PHP version: 5.3.3 Package: Scripting Engine problem Bug Type: Bug Bug description:newline problem with parse_ini_file+INI_SCANNER_RAW Description: If I set the third parameter of the parse_ini_file function to INI_SCANNER_RAW, then the ini file has to end with a newline, else it will trigger a syntax error, unexpected $end warning. The same ini file works with the default scanner_mode(INI_SCANNER_NORMAL), so I think this is a bug. Test script: --- ?php $ini_array = parse_ini_file(test.ini, true, INI_SCANNER_RAW); Expected result: no warning Actual result: -- Warning: syntax error, unexpected $end ... -- Edit bug report at http://bugs.php.net/bug.php?id=52508edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52508r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52508r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52508r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52508r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52508r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52508r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52508r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52508r=needscript Try newer version: http://bugs.php.net/fix.php?id=52508r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52508r=support Expected behavior: http://bugs.php.net/fix.php?id=52508r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52508r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52508r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52508r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52508r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52508r=dst IIS Stability: http://bugs.php.net/fix.php?id=52508r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52508r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52508r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52508r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52508r=mysqlcfg
Bug #52428 [Com]: $this isn't immutable
Edit report at http://bugs.php.net/bug.php?id=52428edit=1
ID: 52428
Comment by: tyra3l at gmail dot com
Reported by:tyra3l at gmail dot com
Summary:$this isn't immutable
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: all
PHP Version:5.3.3
Block user comment: N
New Comment:
what about abolishing everything related to safe_mode
safe_mode has been DEPRECATED as of PHP 5.3.0. and will be removed with
the next
major php version.
Tyrael
Previous Comments:
[2010-07-26 10:32:24] dagdamor10 at mail dot ru
If you want you can shoot yourself in your head.
Okay, that was plain rude.
PHP *should* protect websites from possible exploits, what about
abolishing everything related to safe_mode, allowed paths and such? To
make a good site, people need good programming language... and good
programming language should be accurate in range-checking,
resource-protecting etc, instead of leaving all that to every programmer
who decide to use it.
[2010-07-25 18:50:52] tyra3l at gmail dot com
Thanks for the clarification.
Did I something wrong in the report, or you just copypasted the Thank
you for
taking the time to write to us... part of your comment?
Maybe it would be a good thing to add this conclusion to the
documentation
(reassigning this isn't allowed, because ..., if you try it, it will
give you an
error Cannot re-assign this... [if you really need this, you can
do...])
Tyrael
[2010-07-25 18:39:17] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
We prevent from mistakes, we don't prevent people from hurting them
purposely. If you want you can shoot yourself in your head.
[2010-07-24 11:36:17] tyra3l at gmail dot com
Description:
As some closed bug-reports and the PHP Fatal error: Cannot re-assign
$this
states, the $this should be read-only/inmutable in PHP5.
but with some tricks(variable variables mostly), you can walk-around
this
constraint.
See the Test script.
I don't know the importance of this restriction, and with reflection you
can shoot
you in the leg anyway, so maybe this can be left as is.
Test script:
---
?php
error_reporting(E_ALL);
$var = new StdClass();
$var-foo = 'bar';
//$this = $var; // PHP Fatal error: Cannot re-assign $this
$GLOBALS['this'] = $var;
var_dump($this);
$var-foo = 'baz';
$foo = 'this';
$$foo = $var;
var_dump($this);
foo($this);
function foo($this){
//global $this; // PHP Fatal error: Cannot re-assign $this
// $this = $GLOBALS['var']; // PHP Fatal error: Cannot re-assign
$this
var_dump($this);
$GLOBALS['this']-foo = 'baw';
$$GLOBALS['foo'] = $GLOBALS['this'];
var_dump($this);
}
Expected result:
PHP Fatal error: Cannot re-assign $this
for every attempt to overwrite $this
Actual result:
--
you can set $this in the global scope through $GLOBALS, with argument in
functions, and with variable variables in everywhere.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52428edit=1
Bug #52428 [Com]: $this isn't immutable
Edit report at http://bugs.php.net/bug.php?id=52428edit=1 ID: 52428 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:$this isn't immutable Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: all PHP Version:5.3.3 Block user comment: N New Comment: There was some reason for this check to be placed. My problem with this behaviour that the $bar = 'baz'; should work the same as $foo='bar';$$foo = 'baz'; and same for the $foo vs $GLOBALS['foo'] Tyrael Previous Comments: [2010-07-26 11:20:33] degeb...@php.net @dagdamor10: This has nothing to do with exploits at all. It poses no security risk being able to modify the $this variable by circumventing the simple check that is implemented. [2010-07-26 10:51:25] tyra3l at gmail dot com what about abolishing everything related to safe_mode safe_mode has been DEPRECATED as of PHP 5.3.0. and will be removed with the next major php version. Tyrael [2010-07-26 10:32:24] dagdamor10 at mail dot ru If you want you can shoot yourself in your head. Okay, that was plain rude. PHP *should* protect websites from possible exploits, what about abolishing everything related to safe_mode, allowed paths and such? To make a good site, people need good programming language... and good programming language should be accurate in range-checking, resource-protecting etc, instead of leaving all that to every programmer who decide to use it. [2010-07-25 18:50:52] tyra3l at gmail dot com Thanks for the clarification. Did I something wrong in the report, or you just copypasted the Thank you for taking the time to write to us... part of your comment? Maybe it would be a good thing to add this conclusion to the documentation (reassigning this isn't allowed, because ..., if you try it, it will give you an error Cannot re-assign this... [if you really need this, you can do...]) Tyrael [2010-07-25 18:39:17] johan...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php We prevent from mistakes, we don't prevent people from hurting them purposely. If you want you can shoot yourself in your head. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52428 -- Edit this bug report at http://bugs.php.net/bug.php?id=52428edit=1
Bug #52428 [Bgs]: $this isn't immutable
Edit report at http://bugs.php.net/bug.php?id=52428edit=1
ID: 52428
User updated by: tyra3l at gmail dot com
Reported by: tyra3l at gmail dot com
Summary: $this isn't immutable
Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: all
PHP Version: 5.3.3
New Comment:
Thanks for the clarification.
Did I something wrong in the report, or you just copypasted the Thank
you for
taking the time to write to us... part of your comment?
Maybe it would be a good thing to add this conclusion to the
documentation
(reassigning this isn't allowed, because ..., if you try it, it will
give you an
error Cannot re-assign this... [if you really need this, you can
do...])
Tyrael
Previous Comments:
[2010-07-25 18:39:17] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
We prevent from mistakes, we don't prevent people from hurting them
purposely. If you want you can shoot yourself in your head.
[2010-07-24 11:36:17] tyra3l at gmail dot com
Description:
As some closed bug-reports and the PHP Fatal error: Cannot re-assign
$this
states, the $this should be read-only/inmutable in PHP5.
but with some tricks(variable variables mostly), you can walk-around
this
constraint.
See the Test script.
I don't know the importance of this restriction, and with reflection you
can shoot
you in the leg anyway, so maybe this can be left as is.
Test script:
---
?php
error_reporting(E_ALL);
$var = new StdClass();
$var-foo = 'bar';
//$this = $var; // PHP Fatal error: Cannot re-assign $this
$GLOBALS['this'] = $var;
var_dump($this);
$var-foo = 'baz';
$foo = 'this';
$$foo = $var;
var_dump($this);
foo($this);
function foo($this){
//global $this; // PHP Fatal error: Cannot re-assign $this
// $this = $GLOBALS['var']; // PHP Fatal error: Cannot re-assign
$this
var_dump($this);
$GLOBALS['this']-foo = 'baw';
$$GLOBALS['foo'] = $GLOBALS['this'];
var_dump($this);
}
Expected result:
PHP Fatal error: Cannot re-assign $this
for every attempt to overwrite $this
Actual result:
--
you can set $this in the global scope through $GLOBALS, with argument in
functions, and with variable variables in everywhere.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52428edit=1
[PHP-BUG] Bug #52428 [NEW]: $this isn't immutable
From:
Operating system: all
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:$this isn't immutable
Description:
As some closed bug-reports and the PHP Fatal error: Cannot re-assign
$this
states, the $this should be read-only/inmutable in PHP5.
but with some tricks(variable variables mostly), you can walk-around this
constraint.
See the Test script.
I don't know the importance of this restriction, and with reflection you
can shoot
you in the leg anyway, so maybe this can be left as is.
Test script:
---
?php
error_reporting(E_ALL);
$var = new StdClass();
$var-foo = 'bar';
//$this = $var; // PHP Fatal error: Cannot re-assign $this
$GLOBALS['this'] = $var;
var_dump($this);
$var-foo = 'baz';
$foo = 'this';
$$foo = $var;
var_dump($this);
foo($this);
function foo($this){
//global $this; // PHP Fatal error: Cannot re-assign $this
// $this = $GLOBALS['var']; // PHP Fatal error: Cannot re-assign $this
var_dump($this);
$GLOBALS['this']-foo = 'baw';
$$GLOBALS['foo'] = $GLOBALS['this'];
var_dump($this);
}
Expected result:
PHP Fatal error: Cannot re-assign $this
for every attempt to overwrite $this
Actual result:
--
you can set $this in the global scope through $GLOBALS, with argument in
functions, and with variable variables in everywhere.
--
Edit bug report at http://bugs.php.net/bug.php?id=52428edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52428r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52428r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52428r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52428r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52428r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52428r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52428r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52428r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52428r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52428r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52428r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52428r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52428r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52428r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52428r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52428r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52428r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52428r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52428r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52428r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52428r=mysqlcfg
Bug #51350 [Com]: recursively including non existing file causes segfault
Edit report at http://bugs.php.net/bug.php?id=51350edit=1 ID: 51350 Comment by: tyra3l at gmail dot com Reported by: slogster at gmail dot com Summary: recursively including non existing file causes segfault Status: Bogus Type: Bug Package: Reproducible crash Operating System: freebsd linux PHP Version: 5.2.13 New Comment: afaik you need the suhosin extension for this functionality, not just the patch. http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.max_depth Tyrael Previous Comments: [2010-03-22 22:52:16] slogster at gmail dot com I've tried it with Suhosin-Patch 0.9.7 and it segfaults too [2010-03-22 21:39:15] tyra3l at gmail dot com should worth to reading it. could you at least give me the year for that discussion? I think, that in this case the script should terminate by memory exhaustion (memory_limit) or time_limit exhaustion, not with segfault. In a managed language I shouldn't be able to do stack overflow from userspace. At least not this easily. [2010-03-22 21:29:00] paj...@php.net That's known and there is no bug per se here. Not everything the suhosin patch does is the right thing to do to solve a problem. As far as I remember there was a (long) discussion on internals about this. You may find it interesting. [2010-03-22 21:25:05] tyra3l at gmail dot com suhosin protects against infinite recursion since 2006. if you can crash the php engine from userland, then you can reset the seed http://www.baohx.com/extras/zendcon/lesserknownsecurityproblemsinphpapplications.pdf page 33: attacker can get fresh seed by crashing php. so its not only an inconvinience, but can be a security problem also. Tyrael [2010-03-22 17:45:16] johan...@php.net Recusrion in PHP leads to a stack overflow for the process, which we can't properly handle ourselves so the operating system terminates the PHP process. This is the expected behavior. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51350 -- Edit this bug report at http://bugs.php.net/bug.php?id=51350edit=1
Bug #51463 [Com]: ErrorException thrown from error_handler not catchable in exception handler
Edit report at http://bugs.php.net/bug.php?id=51463edit=1 ID: 51463 Comment by: tyra3l at gmail dot com Reported by: tyra3l at gmail dot com Summary: ErrorException thrown from error_handler not catchable in exception handler Status: Re-Opened Type: Bug Package: Scripting Engine problem Operating System: Windows Xp Sp3, Debian Lenny PHP Version: 5.3.2 New Comment: obviously. closures was added with php 5.3 http://php.net/manual/en/functions.anonymous.php Tyrael Previous Comments: [2010-05-05 20:15:14] whatrevolution at yahoo dot com OP's test code, result: ( ! ) Parse error: syntax error, unexpected T_FUNCTION, expecting ')' in /var/www/php_bugs/exception_in_error_handler.php on line 13 PHP Version 5.2.10-2ubuntu6.4 System Linux 2.6.31-20-generic x86_64 Build Date Jan 6 2010 22:36:47 Server API Apache 2.0 Handler PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 Debug Build no Thread Safety disabled Zend Memory Manager enabled Apache/2.2.12 (Ubuntu) [2010-04-02 15:19:15] tyra3l at gmail dot com Another weird thing that I observed: If I try to handle the fatal error from register shutdown function then the error_get_last() will return NULL if I throw the ErrorException from the error handler. If I don't try to convert exceptions from errors, then the error_get_last() will return the fatal error in the shutdown function. Or if I generate fatal error for example with new NonExistentClassName; then the error_handler doesn't get called (because this is a fatal error), but the shutdown function gets the fatal error with error_get_last() So it seems that there is some strange magic with this situation. Tyrael [2010-04-02 13:41:02] tyra3l at gmail dot com But the exception handler should be called after the error handler and before accessing the empty property which gives the fatal error, isn't it? I mean at first the interpreter tries to access the variable named $foo, then generates a E_NOTICE which is trapped by the error handler, which trows an Exception which never catched at all. [2010-04-02 13:35:54] tyra3l at gmail dot com shit, my mistake, $foo will be empty, so $this-$foo will be generating a fatal error, but before that, generate a warning about $foo is empty. :/ [2010-04-02 13:33:40] tyra3l at gmail dot com On Lenny I was testing with the dotdeb.org 5.3.2 deb, on windows this is the TS VC9 build The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51463 -- Edit this bug report at http://bugs.php.net/bug.php?id=51463edit=1
[PHP-BUG] Bug #51463 [NEW]: ErrorException thrown from error_handler not catchable in exception handler
From:
Operating system: Windows
PHP version: 5.3.2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:ErrorException thrown from error_handler not catchable in
exception handler
Description:
It seems that there are some cases, when you can't catch Exceptions with
exception_handler which was thrown from error_handler for some errors.
For example if you do this:
$class = new StdClass;
echo $class-$foo;
error_handler gets called, ErrorException was thrown, but the Exception
wasn't catched with the exception_handler.
if you try
echo $foo;
instead of
echo $class-$foo;
then the same error gets called with the error handler (by same error, I
mean same parameters), but the Exception thrown in this case is successfuly
catched by the exception handler.
Test script:
---
?php
error_reporting(E_ALL);
ini_set('display_errors', 0);
function debug($s){
echo pre;
var_dump($s);
echo /pre;
}
set_error_handler(
function ($errno, $errstr, $errfile, $errline ) {
debug('error_handler');
debug(array(
'errno' = $errno,
'errstr'= $errstr,
'errfile' = $errfile,
'errline' = $errline,
));
throw new ErrorException($errstr, 0, $errno, $errfile,
$errline);
}
);
set_exception_handler(
function(Exception $e){
debug('exception_handler');
debug($e);
}
);
$class = new StdClass;
echo $class-$foo;
echo 'done';
Expected result:
string(13) error_handler
array(4) {
[errno]=
int(8)
[errstr]=
string(23) Undefined variable: foo
[errfile]=
string(55) C:\work\xampp_vc9\htdocs\default\bug\error_handling.php
[errline]=
int(46)
}
string(17) exception_handler
object(ErrorException)#4 (8) {
[message:protected]=
string(23) Undefined variable: foo
...
Actual result:
--
string(13) error_handler
array(4) {
[errno]=
int(8)
[errstr]=
string(23) Undefined variable: foo
[errfile]=
string(55) C:\work\xampp_vc9\htdocs\default\bug\error_handling.php
[errline]=
int(46)
}
--
Edit bug report at http://bugs.php.net/bug.php?id=51463edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51463r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51463r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51463r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51463r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51463r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51463r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51463r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51463r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51463r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51463r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51463r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51463r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51463r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51463r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51463r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51463r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51463r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51463r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51463r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51463r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51463r=mysqlcfg
Bug #51463 [Opn-Csd]: ErrorException thrown from error_handler not catchable in exception handler
Edit report at http://bugs.php.net/bug.php?id=51463edit=1
ID: 51463
User updated by: tyra3l at gmail dot com
Reported by: tyra3l at gmail dot com
Summary: ErrorException thrown from error_handler not catchable
in exception handler
-Status: Open
+Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: Windows Xp Sp3, Debian Lenny
PHP Version: 5.3.2
New Comment:
shit, my mistake, $foo will be empty, so $this-$foo will be generating
a fatal error, but before that, generate a warning about $foo is empty.
:/
Previous Comments:
[2010-04-02 13:33:40] tyra3l at gmail dot com
On Lenny I was testing with the dotdeb.org 5.3.2 deb, on windows this is
the TS VC9 build
[2010-04-02 13:29:49] tyra3l at gmail dot com
Description:
It seems that there are some cases, when you can't catch Exceptions with
exception_handler which was thrown from error_handler for some errors.
For example if you do this:
$class = new StdClass;
echo $class-$foo;
error_handler gets called, ErrorException was thrown, but the Exception
wasn't catched with the exception_handler.
if you try
echo $foo;
instead of
echo $class-$foo;
then the same error gets called with the error handler (by same error,
I mean same parameters), but the Exception thrown in this case is
successfuly catched by the exception handler.
Test script:
---
?php
error_reporting(E_ALL);
ini_set('display_errors', 0);
function debug($s){
echo pre;
var_dump($s);
echo /pre;
}
set_error_handler(
function ($errno, $errstr, $errfile, $errline ) {
debug('error_handler');
debug(array(
'errno' = $errno,
'errstr'= $errstr,
'errfile' = $errfile,
'errline' = $errline,
));
throw new ErrorException($errstr, 0, $errno, $errfile,
$errline);
}
);
set_exception_handler(
function(Exception $e){
debug('exception_handler');
debug($e);
}
);
$class = new StdClass;
echo $class-$foo;
echo 'done';
Expected result:
string(13) error_handler
array(4) {
[errno]=
int(8)
[errstr]=
string(23) Undefined variable: foo
[errfile]=
string(55) C:\work\xampp_vc9\htdocs\default\bug\error_handling.php
[errline]=
int(46)
}
string(17) exception_handler
object(ErrorException)#4 (8) {
[message:protected]=
string(23) Undefined variable: foo
...
Actual result:
--
string(13) error_handler
array(4) {
[errno]=
int(8)
[errstr]=
string(23) Undefined variable: foo
[errfile]=
string(55) C:\work\xampp_vc9\htdocs\default\bug\error_handling.php
[errline]=
int(46)
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=51463edit=1
Bug #51463 [Csd]: ErrorException thrown from error_handler not catchable in exception handler
Edit report at http://bugs.php.net/bug.php?id=51463edit=1
ID: 51463
User updated by: tyra3l at gmail dot com
Reported by: tyra3l at gmail dot com
Summary: ErrorException thrown from error_handler not catchable
in exception handler
Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: Windows Xp Sp3, Debian Lenny
PHP Version: 5.3.2
New Comment:
But the exception handler should be called after the error handler and
before accessing the empty property which gives the fatal error, isn't
it?
I mean at first the interpreter tries to access the variable named $foo,
then generates a E_NOTICE which is trapped by the error handler, which
trows an Exception which never catched at all.
Previous Comments:
[2010-04-02 13:35:54] tyra3l at gmail dot com
shit, my mistake, $foo will be empty, so $this-$foo will be generating
a fatal error, but before that, generate a warning about $foo is empty.
:/
[2010-04-02 13:33:40] tyra3l at gmail dot com
On Lenny I was testing with the dotdeb.org 5.3.2 deb, on windows this is
the TS VC9 build
[2010-04-02 13:29:49] tyra3l at gmail dot com
Description:
It seems that there are some cases, when you can't catch Exceptions with
exception_handler which was thrown from error_handler for some errors.
For example if you do this:
$class = new StdClass;
echo $class-$foo;
error_handler gets called, ErrorException was thrown, but the Exception
wasn't catched with the exception_handler.
if you try
echo $foo;
instead of
echo $class-$foo;
then the same error gets called with the error handler (by same error,
I mean same parameters), but the Exception thrown in this case is
successfuly catched by the exception handler.
Test script:
---
?php
error_reporting(E_ALL);
ini_set('display_errors', 0);
function debug($s){
echo pre;
var_dump($s);
echo /pre;
}
set_error_handler(
function ($errno, $errstr, $errfile, $errline ) {
debug('error_handler');
debug(array(
'errno' = $errno,
'errstr'= $errstr,
'errfile' = $errfile,
'errline' = $errline,
));
throw new ErrorException($errstr, 0, $errno, $errfile,
$errline);
}
);
set_exception_handler(
function(Exception $e){
debug('exception_handler');
debug($e);
}
);
$class = new StdClass;
echo $class-$foo;
echo 'done';
Expected result:
string(13) error_handler
array(4) {
[errno]=
int(8)
[errstr]=
string(23) Undefined variable: foo
[errfile]=
string(55) C:\work\xampp_vc9\htdocs\default\bug\error_handling.php
[errline]=
int(46)
}
string(17) exception_handler
object(ErrorException)#4 (8) {
[message:protected]=
string(23) Undefined variable: foo
...
Actual result:
--
string(13) error_handler
array(4) {
[errno]=
int(8)
[errstr]=
string(23) Undefined variable: foo
[errfile]=
string(55) C:\work\xampp_vc9\htdocs\default\bug\error_handling.php
[errline]=
int(46)
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=51463edit=1
Bug #51463 [ReO]: ErrorException thrown from error_handler not catchable in exception handler
Edit report at http://bugs.php.net/bug.php?id=51463edit=1
ID: 51463
User updated by: tyra3l at gmail dot com
Reported by: tyra3l at gmail dot com
Summary: ErrorException thrown from error_handler not catchable
in exception handler
Status: Re-Opened
Type: Bug
Package: Scripting Engine problem
Operating System: Windows Xp Sp3, Debian Lenny
PHP Version: 5.3.2
New Comment:
Another weird thing that I observed:
If I try to handle the fatal error from register shutdown function then
the error_get_last() will return NULL if I throw the ErrorException from
the error handler.
If I don't try to convert exceptions from errors, then the
error_get_last() will return the fatal error in the shutdown function.
Or if I generate fatal error for example with
new NonExistentClassName;
then the error_handler doesn't get called (because this is a fatal
error), but the shutdown function gets the fatal error with
error_get_last()
So it seems that there is some strange magic with this situation.
Tyrael
Previous Comments:
[2010-04-02 13:41:02] tyra3l at gmail dot com
But the exception handler should be called after the error handler and
before accessing the empty property which gives the fatal error, isn't
it?
I mean at first the interpreter tries to access the variable named $foo,
then generates a E_NOTICE which is trapped by the error handler, which
trows an Exception which never catched at all.
[2010-04-02 13:35:54] tyra3l at gmail dot com
shit, my mistake, $foo will be empty, so $this-$foo will be generating
a fatal error, but before that, generate a warning about $foo is empty.
:/
[2010-04-02 13:33:40] tyra3l at gmail dot com
On Lenny I was testing with the dotdeb.org 5.3.2 deb, on windows this is
the TS VC9 build
[2010-04-02 13:29:49] tyra3l at gmail dot com
Description:
It seems that there are some cases, when you can't catch Exceptions with
exception_handler which was thrown from error_handler for some errors.
For example if you do this:
$class = new StdClass;
echo $class-$foo;
error_handler gets called, ErrorException was thrown, but the Exception
wasn't catched with the exception_handler.
if you try
echo $foo;
instead of
echo $class-$foo;
then the same error gets called with the error handler (by same error,
I mean same parameters), but the Exception thrown in this case is
successfuly catched by the exception handler.
Test script:
---
?php
error_reporting(E_ALL);
ini_set('display_errors', 0);
function debug($s){
echo pre;
var_dump($s);
echo /pre;
}
set_error_handler(
function ($errno, $errstr, $errfile, $errline ) {
debug('error_handler');
debug(array(
'errno' = $errno,
'errstr'= $errstr,
'errfile' = $errfile,
'errline' = $errline,
));
throw new ErrorException($errstr, 0, $errno, $errfile,
$errline);
}
);
set_exception_handler(
function(Exception $e){
debug('exception_handler');
debug($e);
}
);
$class = new StdClass;
echo $class-$foo;
echo 'done';
Expected result:
string(13) error_handler
array(4) {
[errno]=
int(8)
[errstr]=
string(23) Undefined variable: foo
[errfile]=
string(55) C:\work\xampp_vc9\htdocs\default\bug\error_handling.php
[errline]=
int(46)
}
string(17) exception_handler
object(ErrorException)#4 (8) {
[message:protected]=
string(23) Undefined variable: foo
...
Actual result:
--
string(13) error_handler
array(4) {
[errno]=
int(8)
[errstr]=
string(23) Undefined variable: foo
[errfile]=
string(55) C:\work\xampp_vc9\htdocs\default\bug\error_handling.php
[errline]=
int(46)
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=51463edit=1
Bug #51350 [Com]: recursively including non existing file causes segfault
Edit report at http://bugs.php.net/bug.php?id=51350edit=1
ID: 51350
Comment by: tyra3l at gmail dot com
Reported by: slogster at gmail dot com
Summary: recursively including non existing file causes
segfault
Status: Bogus
Type: Bug
Package: Reproducible crash
Operating System: freebsd linux
PHP Version: 5.2.13
New Comment:
suhosin protects against infinite recursion since 2006.
if you can crash the php engine from userland, then you can reset the
seed
http://www.baohx.com/extras/zendcon/lesserknownsecurityproblemsinphpapplications.pdf
page 33: attacker can get fresh seed by crashing php.
so its not only an inconvinience, but can be a security problem also.
Tyrael
Previous Comments:
[2010-03-22 17:45:16] johan...@php.net
Recusrion in PHP leads to a stack overflow for the process, which we
can't properly handle ourselves so the operating system terminates the
PHP process. This is the expected behavior.
[2010-03-22 17:08:20] slogster at gmail dot com
Description:
function a(){include(/nofile); a();} a();
/nofine is non existing file
Test script:
---
function a(){include(/nofile); a();} a();
/nofile is non existing file
Expected result:
should not segfault
Actual result:
--
segfault
--
Edit this bug report at http://bugs.php.net/bug.php?id=51350edit=1
Bug #51350 [Com]: recursively including non existing file causes segfault
Edit report at http://bugs.php.net/bug.php?id=51350edit=1
ID: 51350
Comment by: tyra3l at gmail dot com
Reported by: slogster at gmail dot com
Summary: recursively including non existing file causes
segfault
Status: Bogus
Type: Bug
Package: Reproducible crash
Operating System: freebsd linux
PHP Version: 5.2.13
New Comment:
should worth to reading it.
could you at least give me the year for that discussion?
I think, that in this case the script should terminate by memory
exhaustion (memory_limit) or time_limit exhaustion, not with segfault.
In a managed language I shouldn't be able to do stack overflow from
userspace.
At least not this easily.
Previous Comments:
[2010-03-22 21:29:00] paj...@php.net
That's known and there is no bug per se here.
Not everything the suhosin patch does is the right thing to do to solve
a problem. As far as I remember there was a (long) discussion on
internals about this. You may find it interesting.
[2010-03-22 21:25:05] tyra3l at gmail dot com
suhosin protects against infinite recursion since 2006.
if you can crash the php engine from userland, then you can reset the
seed
http://www.baohx.com/extras/zendcon/lesserknownsecurityproblemsinphpapplications.pdf
page 33: attacker can get fresh seed by crashing php.
so its not only an inconvinience, but can be a security problem also.
Tyrael
[2010-03-22 17:45:16] johan...@php.net
Recusrion in PHP leads to a stack overflow for the process, which we
can't properly handle ourselves so the operating system terminates the
PHP process. This is the expected behavior.
[2010-03-22 17:08:20] slogster at gmail dot com
Description:
function a(){include(/nofile); a();} a();
/nofine is non existing file
Test script:
---
function a(){include(/nofile); a();} a();
/nofile is non existing file
Expected result:
should not segfault
Actual result:
--
segfault
--
Edit this bug report at http://bugs.php.net/bug.php?id=51350edit=1
#50255 [Ver]: isset() and empty() silently casts array to object?
ID: 50255
User updated by: tyra3l at gmail dot com
Reported By: tyra3l at gmail dot com
Status: Verified
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.*, 6
New Comment:
Thank you for verifying this.
It was noticed on our development machines, and I tested it on
different
php installations, so I can confirm this is also present on
5.2.5,5.2.8,5.2.11 also.
Tyrael
Previous Comments:
[2009-11-23 13:28:40] j...@php.net
I'm sorry, I read this a bit hastily. This indeed is a bug.
[2009-11-21 21:13:49] tyra3l at gmail dot com
could you show me which ticket duplicates this, and where this behavior
is documented in the manual?
because I tried to check this in the documentation, but I haven't found
it at the isset/empty manual page.
Tyrael
[2009-11-21 10:08:26] tyra3l at gmail dot com
Description:
If you try to check the existence of a property on an array,
suprisingly you wont get any error or notice, but you will get the
results as you were checking with the correct type.
Reproduce code:
---
?php
$a = array('foo' = 'bar');
echo pre;var_dump(isset($a-foo));echo /pre;
echo pre;var_dump(isset($a-asd));echo /pre;
echo pre;var_dump(empty($a-foo));echo /pre;
echo pre;var_dump(empty($a-asd));echo /pre;
echo pre;var_dump(@$a-foo);echo /pre;
Expected result:
Fatal error: Cannot use array as object in ...
OR
bool(false)
bool(false)
bool(true)
bool(true)
NULL
Actual result:
--
bool(true)
bool(false)
bool(false)
bool(true)
NULL
--
Edit this bug report at http://bugs.php.net/?id=50255edit=1
#50255 [NEW]: isset and empty returns wrong value
From: tyra3l at gmail dot com
Operating system: windows xp
PHP version: 5.3.1
PHP Bug Type: *General Issues
Bug description: isset and empty returns wrong value
Description:
If you try to check the existence of a property on an array, suprisingly
you wont get any error or notice, but you will get the results as you were
checking with the correct type.
Reproduce code:
---
?php
$a = array('foo' = 'bar');
echo pre;var_dump(isset($a-foo));echo /pre;
echo pre;var_dump(isset($a-asd));echo /pre;
echo pre;var_dump(empty($a-foo));echo /pre;
echo pre;var_dump(empty($a-asd));echo /pre;
echo pre;var_dump(@$a-foo);echo /pre;
Expected result:
Fatal error: Cannot use array as object in ...
OR
bool(false)
bool(false)
bool(true)
bool(true)
NULL
Actual result:
--
bool(true)
bool(false)
bool(false)
bool(true)
NULL
--
Edit bug report at http://bugs.php.net/?id=50255edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50255r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50255r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50255r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50255r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50255r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50255r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50255r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50255r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50255r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50255r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50255r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50255r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50255r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50255r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50255r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50255r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50255r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50255r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50255r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50255r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50255r=mysqlcfg
#50255 [Bgs]: isset and empty returns wrong value
ID: 50255
User updated by: tyra3l at gmail dot com
Reported By: tyra3l at gmail dot com
Status: Bogus
Bug Type: *General Issues
Operating System: windows xp
PHP Version: 5.3.1
New Comment:
could you show me which ticket duplicates this, and where this behavior
is documented in the manual?
because I tried to check this in the documentation, but I haven't found
it at the isset/empty manual page.
Tyrael
Previous Comments:
[2009-11-21 15:00:19] j...@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
And expected behaviour. RTFM. etc.
[2009-11-21 10:08:26] tyra3l at gmail dot com
Description:
If you try to check the existence of a property on an array,
suprisingly you wont get any error or notice, but you will get the
results as you were checking with the correct type.
Reproduce code:
---
?php
$a = array('foo' = 'bar');
echo pre;var_dump(isset($a-foo));echo /pre;
echo pre;var_dump(isset($a-asd));echo /pre;
echo pre;var_dump(empty($a-foo));echo /pre;
echo pre;var_dump(empty($a-asd));echo /pre;
echo pre;var_dump(@$a-foo);echo /pre;
Expected result:
Fatal error: Cannot use array as object in ...
OR
bool(false)
bool(false)
bool(true)
bool(true)
NULL
Actual result:
--
bool(true)
bool(false)
bool(false)
bool(true)
NULL
--
Edit this bug report at http://bugs.php.net/?id=50255edit=1
#48184 [NEW]: Missing extensions and so
From: tyra3l at gmail dot com Operating system: Windows XP SP3 PHP version: 5.3.0RC2 PHP Bug Type: *Configuration Issues Bug description: Missing extensions and so Description: Problems with the default php extensions in the example php.ini.* Reproduce code: --- Try to enable the modules. Expected result: We should only have the shipped extensions in the php.ini by default, and every module should be working (which doesn't have some 3rd party dependency) Actual result: -- php_curl.dll = missing zlib.dll php_dba.dll = missing php_exif.dll = missing php_mbstring.dll (weird) php_gmp.dll = missing php_intl.dll = missing icuuc36.dll php_interbase.dll = missing gds32.dll php_mime_magic.dll = missing php_ming.dll = missing php_mssql.dll = missing ntwdblib.dll php_oci8.dll = missing OCI.dll php_oci8_11g.dll = missing OCI.dll php_pdo_firebird.dll = missing gds32.dll php_pdo_mssql.dll = missing ntwdblib.dll php_pdo_oci.dll = missing OCI.dll php_pdo_pgsql.dll = missing LIBPQ.dll php_pgsql.dll = missing LIBPQ.dll php_phar.dll = missing php_pspell.dll = aspell-15.dll php_snmp.dll = missing php_sybase_ct.dll = missing libcs.dll php_zip.dll = missing As far as I can see: - the config contains extensions, which isn't shipped - the config contains extensions, which are shipped, but cannot be loaded without the proper third party lib. - some exts are broken (curl was working fine in the RC1) I think that the lines without the extension should be removed, the lines with an ext which has dependency should be noted like with the oracle drivers. The broken exts should be fixed(curl, exif) -- Edit bug report at http://bugs.php.net/?id=48184edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48184r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48184r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48184r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48184r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48184r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48184r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48184r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48184r=needscript Try newer version: http://bugs.php.net/fix.php?id=48184r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48184r=support Expected behavior: http://bugs.php.net/fix.php?id=48184r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48184r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48184r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48184r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48184r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48184r=dst IIS Stability: http://bugs.php.net/fix.php?id=48184r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48184r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48184r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48184r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48184r=mysqlcfg
#48184 [Ana]: Missing extensions and so
ID: 48184 User updated by: tyra3l at gmail dot com Reported By: tyra3l at gmail dot com Status: Analyzed Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0RC2 Assigned To: pajoye New Comment: Ok, I know about the db drivers dependency, but if you can mention this about the oracle driver, it should be noted for the others too. The lines about the built-in and the not-supported-yet modules should be removed, so the php.ini and the actual extension should be kept in sync imho. If the exif ext depends on the mbstring, then it should be put after that. Could this mean, that we could have some cycle reference error about the extensions loading preference, for example: If A depends on B and B on C and C on A, then it can be loaded? Sorry for asking stopid questions. :/ ps: Can I get/build somehow the curl module for myself, or it wont work with the current RC? Tyrael Previous Comments: [2009-05-07 19:14:08] paj...@php.net In short, I will repackage it without mssql as it makes no sense to bundle it as it is not support anymore in 5.3. Thanks for your quick testreport! [2009-05-07 19:13:13] paj...@php.net php -m output: [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib And the one I miss: php_dba.dll = missing not supported yet. php_exif.dll = missing php_mbstring.dll (weird) It depends on mbstring, load mbsring first. See the manual. php_gmp.dll = missing not support yet. php_intl.dll = missing icuuc36.dll it is in the archive. [2009-05-07 19:09:23] paj...@php.net php_curl.dll = missing zlib.dll php_dba.dll = missing php_exif.dll = missing php_mbstring.dll (weird) php_gmp.dll = missing php_intl.dll = missing icuuc36.dll php_interbase.dll = missing gds32.dll not supported yet. php_mime_magic.dll = missing php_ming.dll = missing moved to pecl php_mssql.dll = missing ntwdblib.dll not available anymore, my mistake I should have disabled it. php_oci8.dll = missing OCI.dll You have to install the OCI client. See the manual. php_oci8_11g.dll = missing OCI.dll Same as oci8 but using the client version 11.x. php_pdo_firebird.dll = missing gds32.dll Not supported yet. php_pdo_mssql.dll = missing ntwdblib.dll not available anymore, my mistake I should have disabled it. php_pdo_oci.dll = missing OCI.dll Same as oci8 php_pdo_pgsql.dll = missing LIBPQ.dll It is present in the archive. php_pgsql.dll = missing LIBPQ.dll It is present in the archive. php_phar.dll = missing builtin php_pspell.dll = aspell-15.dll not supported anymore. php_snmp.dll = missing not supported yet. php_sybase_ct.dll = missing libcs.dll You have to install the sybase client. php_zip.dll = missing builtin. For builtin module: run php -m to see them. [2009-05-07 18:31:44] tyra3l at gmail dot com Description: Problems with the default php extensions in the example php.ini.* Reproduce code: --- Try to enable the modules. Expected result: We should only have the shipped extensions in the php.ini by default, and every module should be working (which doesn't have some 3rd party dependency) Actual result: -- php_curl.dll = missing zlib.dll php_dba.dll = missing php_exif.dll = missing php_mbstring.dll (weird) php_gmp.dll = missing php_intl.dll = missing icuuc36.dll php_interbase.dll = missing gds32.dll php_mime_magic.dll = missing php_ming.dll = missing php_mssql.dll = missing ntwdblib.dll php_oci8.dll = missing OCI.dll php_oci8_11g.dll = missing OCI.dll php_pdo_firebird.dll = missing gds32.dll php_pdo_mssql.dll = missing ntwdblib.dll php_pdo_oci.dll = missing OCI.dll php_pdo_pgsql.dll = missing LIBPQ.dll php_pgsql.dll = missing LIBPQ.dll php_phar.dll = missing php_pspell.dll = aspell-15.dll php_snmp.dll = missing php_sybase_ct.dll = missing libcs.dll php_zip.dll = missing As far as I can see: - the config contains extensions, which isn't shipped - the config contains extensions, which are shipped, but cannot be loaded without the proper third party lib. - some exts are broken (curl was working fine in the RC1) I think that the lines without the extension should be removed, the lines with an ext which has dependency should be noted like with the oracle drivers. The broken exts should be fixed(curl, exif) -- Edit this bug report at http://bugs.php.net/?id=48184edit=1
#48184 [Fbk-Opn]: Missing extensions and so
ID: 48184 User updated by: tyra3l at gmail dot com Reported By: tyra3l at gmail dot com -Status: Feedback +Status: Open Bug Type: *Configuration Issues Operating System: Windows XP SP3 PHP Version: 5.3.0RC2 Assigned To: pajoye New Comment: curl is working with the updated package. mssql, and pdo_mssql are removed now, but they weren't removed from the php.ini. also it seems that enchant was shipped with RC1(and mentioned on the release note), but the php.ini hasn't note it in the extensions, and now its gone with RC2. what happened with it? Its my biggest problem (after you fixed the curl extension, of course :)), that the php.ini isn't reflect the situation about the shipped/packaged extensions. thanks for your time and effort. Tyrael Previous Comments: [2009-05-07 20:43:36] paj...@php.net Please retry :) [2009-05-07 19:26:51] tyra3l at gmail dot com Ok, I know about the db drivers dependency, but if you can mention this about the oracle driver, it should be noted for the others too. The lines about the built-in and the not-supported-yet modules should be removed, so the php.ini and the actual extension should be kept in sync imho. If the exif ext depends on the mbstring, then it should be put after that. Could this mean, that we could have some cycle reference error about the extensions loading preference, for example: If A depends on B and B on C and C on A, then it can be loaded? Sorry for asking stopid questions. :/ ps: Can I get/build somehow the curl module for myself, or it wont work with the current RC? Tyrael [2009-05-07 19:14:08] paj...@php.net In short, I will repackage it without mssql as it makes no sense to bundle it as it is not support anymore in 5.3. Thanks for your quick testreport! [2009-05-07 19:13:13] paj...@php.net php -m output: [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib And the one I miss: php_dba.dll = missing not supported yet. php_exif.dll = missing php_mbstring.dll (weird) It depends on mbstring, load mbsring first. See the manual. php_gmp.dll = missing not support yet. php_intl.dll = missing icuuc36.dll it is in the archive. [2009-05-07 19:09:23] paj...@php.net php_curl.dll = missing zlib.dll php_dba.dll = missing php_exif.dll = missing php_mbstring.dll (weird) php_gmp.dll = missing php_intl.dll = missing icuuc36.dll php_interbase.dll = missing gds32.dll not supported yet. php_mime_magic.dll = missing php_ming.dll = missing moved to pecl php_mssql.dll = missing ntwdblib.dll not available anymore, my mistake I should have disabled it. php_oci8.dll = missing OCI.dll You have to install the OCI client. See the manual. php_oci8_11g.dll = missing OCI.dll Same as oci8 but using the client version 11.x. php_pdo_firebird.dll = missing gds32.dll Not supported yet. php_pdo_mssql.dll = missing ntwdblib.dll not available anymore, my mistake I should have disabled it. php_pdo_oci.dll = missing OCI.dll Same as oci8 php_pdo_pgsql.dll = missing LIBPQ.dll It is present in the archive. php_pgsql.dll = missing LIBPQ.dll It is present in the archive. php_phar.dll = missing builtin php_pspell.dll = aspell-15.dll not supported anymore. php_snmp.dll = missing not supported yet. php_sybase_ct.dll = missing libcs.dll You have to install the sybase client. php_zip.dll = missing builtin. For builtin module: run php -m to see them. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48184 -- Edit this bug report at http://bugs.php.net/?id=48184edit=1
#48184 [Asn]: Missing extensions and so
ID: 48184 User updated by: tyra3l at gmail dot com Reported By: tyra3l at gmail dot com Status: Assigned Bug Type: Dynamic loading Operating System: win32 only - Windows XP SP3 PHP Version: 5.3.0RC2 Assigned To: pajoye New Comment: About the intl extension: If I move the following dlls: icudt36.dll icuin36.dll icuio36.dll icule36.dll iculx36.dll icutu36.dll icuuc36.dll from the php directory to the apache/bin, then it works. this is my fault, how/where can I tell the php, that where should it search the extensions dll dependecy? Tyrael Previous Comments: [2009-05-07 21:35:20] tyra3l at gmail dot com curl is working with the updated package. mssql, and pdo_mssql are removed now, but they weren't removed from the php.ini. also it seems that enchant was shipped with RC1(and mentioned on the release note), but the php.ini hasn't note it in the extensions, and now its gone with RC2. what happened with it? Its my biggest problem (after you fixed the curl extension, of course :)), that the php.ini isn't reflect the situation about the shipped/packaged extensions. thanks for your time and effort. Tyrael [2009-05-07 20:43:36] paj...@php.net Please retry :) [2009-05-07 19:26:51] tyra3l at gmail dot com Ok, I know about the db drivers dependency, but if you can mention this about the oracle driver, it should be noted for the others too. The lines about the built-in and the not-supported-yet modules should be removed, so the php.ini and the actual extension should be kept in sync imho. If the exif ext depends on the mbstring, then it should be put after that. Could this mean, that we could have some cycle reference error about the extensions loading preference, for example: If A depends on B and B on C and C on A, then it can be loaded? Sorry for asking stopid questions. :/ ps: Can I get/build somehow the curl module for myself, or it wont work with the current RC? Tyrael [2009-05-07 19:14:08] paj...@php.net In short, I will repackage it without mssql as it makes no sense to bundle it as it is not support anymore in 5.3. Thanks for your quick testreport! [2009-05-07 19:13:13] paj...@php.net php -m output: [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib And the one I miss: php_dba.dll = missing not supported yet. php_exif.dll = missing php_mbstring.dll (weird) It depends on mbstring, load mbsring first. See the manual. php_gmp.dll = missing not support yet. php_intl.dll = missing icuuc36.dll it is in the archive. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48184 -- Edit this bug report at http://bugs.php.net/?id=48184edit=1
