[PHP-BUG] Bug #53104 [NEW]: min() and max() treat null differently
From: Operating system: Windows 2000 Pro SP4 PHP version: 5.3.3 Package: Math related Bug Type: Bug Bug description:min() and max() treat null differently Description: The min() and max() functions treat null values as "negative infinity", which is not documented or (to me) particularly intuitive. I would expect null to either be treated as 0 (as "(int)null" does), or ignore it entirely (which min() does not, but max() does by virtue of any value being greater than negative infinity). Test script: --- echo "min(-1,null) = "; var_dump(min(-1,null)); echo "\n"; /* NULL*/ echo "min( 1,null) = "; var_dump(min( 1,null)); echo "\n"; /* NULL*/ echo "max(-1,null) = "; var_dump(max(-1,null)); echo "\n"; /* int(-1) */ echo "max( 1,null) = "; var_dump(max( 1,null)); echo "\n"; /* int(1) */ Expected result: min(-1,null) = int(-1) min( 1,null) = int(1 or 0) max(-1,null) = int(-1 or 0) max( 1,null) = int(1) Actual result: -- min(-1,null) = NULL min( 1,null) = NULL max(-1,null) = int(-1) max( 1,null) = int(1) -- Edit bug report at http://bugs.php.net/bug.php?id=53104&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53104&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53104&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53104&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53104&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53104&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53104&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53104&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53104&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53104&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53104&r=support Expected behavior: http://bugs.php.net/fix.php?id=53104&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53104&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53104&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53104&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53104&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53104&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53104&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53104&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53104&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53104&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53104&r=mysqlcfg
#49295 [NoF->Opn]: stream_socket_client() fails on SSL+async
ID: 49295 User updated by: frase at cs dot wisc dot edu Reported By: frase at cs dot wisc dot edu -Status: No Feedback +Status: Open Bug Type: OpenSSL related Operating System: win32 only - Win 2000 Pro SP4 -PHP Version: 5.2.11RC2 +PHP Version: 5.2.11, 5.3.1 Assigned To: srinatar New Comment: This bug was "suspended automatically" by the bug system because "no feedback was provided for this bug for over a week," although it seems to me the feedback required is from a PHP developer, not from me. Nonetheless, here's some feedback to reopen it: I'd still love to see this fixed. :) Previous Comments: [2009-12-19 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-12-11 01:09:59] paj...@php.net Having read the backlog, will you work on that or completely give up on this bug (saw that you unassigned this bug)? [2009-09-16 18:22:57] srina...@php.net as i mentioned to you last time, our openssl implementation is incorrectly using file based sockets instead of openssl provided 'BIO' for underlying communication. this will require re-implementation of some of php's openssl implementation. this should be an issue only on windows. ------------------------ [2009-09-04 13:21:10] frase at cs dot wisc dot edu I'm sure this is expected, but the bug remains in 5.2.11RC2. I also noticed another clue: I mentioned previously that SSL+ASYNC works once (but not asynchronously) after starting Apache, and then fails and throws warnings. It turns out any SSL socket connection will cause future SSL+ASYNC attempts to do this, even if the first one was SYNC. So to get SSL+ASYNC to connect, it must be the very first SSL socket opened since Apache started. -------------------- [2009-09-02 14:17:18] frase at cs dot wisc dot edu Commenting the stream_set_blocking() doesn't change anything for me on Windows. SSL+ASYNC still works exactly once (but doesn't actually connect asynchronously) and then gives the warnings; SSL+SYNC still works fine, as does TCP+ASYNC. Thanks for your work on this. I get complaints about it every week because if the remote server doesn't respond then our software gets stuck in the connection phase, and since the connection phase cannot be made asynchronous, the user is unable to abort it and just has to wait. 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/49295 -- Edit this bug report at http://bugs.php.net/?id=49295&edit=1
#49295 [Asn]: stream_socket_client() fails on SSL+async
ID: 49295 User updated by: frase at cs dot wisc dot edu Reported By: frase at cs dot wisc dot edu Status: Assigned Bug Type: OpenSSL related Operating System: Win 2000 Pro SP4 -PHP Version: 5.2.11RC1 +PHP Version: 5.2.11RC2 Assigned To: srinatar New Comment: I'm sure this is expected, but the bug remains in 5.2.11RC2. I also noticed another clue: I mentioned previously that SSL+ASYNC works once (but not asynchronously) after starting Apache, and then fails and throws warnings. It turns out any SSL socket connection will cause future SSL+ASYNC attempts to do this, even if the first one was SYNC. So to get SSL+ASYNC to connect, it must be the very first SSL socket opened since Apache started. Previous Comments: [2009-09-02 14:17:18] frase at cs dot wisc dot edu Commenting the stream_set_blocking() doesn't change anything for me on Windows. SSL+ASYNC still works exactly once (but doesn't actually connect asynchronously) and then gives the warnings; SSL+SYNC still works fine, as does TCP+ASYNC. Thanks for your work on this. I get complaints about it every week because if the remote server doesn't respond then our software gets stuck in the connection phase, and since the connection phase cannot be made asynchronous, the user is unable to abort it and just has to wait. [2009-09-02 08:38:01] srina...@php.net just a follow up note, this issue (async not working consistently with openssl on windows) has always been the case and this issue has nothing to do with the fix that went in for bug:48182. [2009-09-02 08:09:22] srina...@php.net ok, i was looking into this issue today. the issue is that , especially on windows -where sockets are not file descriptors unlike in unix, async sockets and openssl works together only if we use BIO wrappers provided by openssl module instead of directly accessing underlying sockets as file descriptors. the possible right way to do this would be to use to socket wrappers provided by SSL module (known as BIO wrappers which makes it work properly on windows). this will require some amount of fiddling our openssl module. i don't think, 5.2 is a good place to do this change. for now, commenting this below code should help you to run your script properly on windows. stream_set_blocking($socket, 0); i will spend more time on this and investigate on the best way to use BIO wrappers within existing openssl module say within php 5.3 ---- [2009-08-21 15:05:47] frase at cs dot wisc dot edu I had a chance to compile and test PHP5.2.11RC1 under Linux this morning (Ubuntu Jaunty, Apache 2.2.11 from repositories), and these warnings do not appear, however I noticed another problem. Although the SSL+async connection is successful and data is returned under Linux, the socket is not actually opened asynchonously. The script blocks until the socket has finished opening, exactly as it does without the ASYNC flag. This is also true under Windows, for the first run -- after that, of course, it returns the errors posted above. [2009-08-21 01:15:44] srina...@php.net this issue seems to be happening when this script is executed more than once and also seems to be happening only on windows. 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/49295 -- Edit this bug report at http://bugs.php.net/?id=49295&edit=1
#49295 [Com]: stream_socket_client() fails on SSL+async
ID: 49295 Comment by: frase at cs dot wisc dot edu Reported By: frase at cs dot wisc dot edu Status: Assigned Bug Type: OpenSSL related Operating System: Win 2000 Pro SP4 PHP Version: 5.2.11RC1 Assigned To: srinatar New Comment: Commenting the stream_set_blocking() doesn't change anything for me on Windows. SSL+ASYNC still works exactly once (but doesn't actually connect asynchronously) and then gives the warnings; SSL+SYNC still works fine, as does TCP+ASYNC. Thanks for your work on this. I get complaints about it every week because if the remote server doesn't respond then our software gets stuck in the connection phase, and since the connection phase cannot be made asynchronous, the user is unable to abort it and just has to wait. Previous Comments: [2009-09-02 08:38:01] srina...@php.net just a follow up note, this issue (async not working consistently with openssl on windows) has always been the case and this issue has nothing to do with the fix that went in for bug:48182. [2009-09-02 08:09:22] srina...@php.net ok, i was looking into this issue today. the issue is that , especially on windows -where sockets are not file descriptors unlike in unix, async sockets and openssl works together only if we use BIO wrappers provided by openssl module instead of directly accessing underlying sockets as file descriptors. the possible right way to do this would be to use to socket wrappers provided by SSL module (known as BIO wrappers which makes it work properly on windows). this will require some amount of fiddling our openssl module. i don't think, 5.2 is a good place to do this change. for now, commenting this below code should help you to run your script properly on windows. stream_set_blocking($socket, 0); i will spend more time on this and investigate on the best way to use BIO wrappers within existing openssl module say within php 5.3 [2009-08-21 15:05:47] frase at cs dot wisc dot edu I had a chance to compile and test PHP5.2.11RC1 under Linux this morning (Ubuntu Jaunty, Apache 2.2.11 from repositories), and these warnings do not appear, however I noticed another problem. Although the SSL+async connection is successful and data is returned under Linux, the socket is not actually opened asynchonously. The script blocks until the socket has finished opening, exactly as it does without the ASYNC flag. This is also true under Windows, for the first run -- after that, of course, it returns the errors posted above. [2009-08-21 01:15:44] srina...@php.net this issue seems to be happening when this script is executed more than once and also seems to be happening only on windows. [2009-08-19 13:52:18] frase at cs dot wisc dot edu Description: stream_socket_client() can only open one socket using SSL and the STREAM_CLIENT_ASYNC_CONNECT flag, and then fails every time until the Apache process is restarted. SSL sockets without ASYNC open fine, as do plain TCP sockets with or without ASYNC. Originally reported as an update to bug #48182, which also only affected the combination of SSL+ASYNC, but now reported separately here per srina...@php.net's request. Additionally, the timeout (argument #4 to stream_socket_client()) is not ignored when using ASYNC, contrary to the manual: if set to 0 here, the first warning is "SSL: connection timeout" instead of "SSL: The operation completed successfully." Windows 2000 Professional SP4 Apache 2.2.11 PHP 5.2.11RC1-Win32-VC6-x86 (threadsafe binary from http://windows.php.net/qa/) configured as an Apache module with php_openssl.dll and libeay32.dll+ssleay.dll v0.9.8k Reproduce code: --- http://bugs.php.net/?id=49295&edit=1
#49295 [Com]: stream_socket_client() fails on SSL+async
ID: 49295 Comment by: frase at cs dot wisc dot edu Reported By: frase at cs dot wisc dot edu Status: Assigned Bug Type: OpenSSL related Operating System: Win 2000 Pro SP4 PHP Version: 5.2.11RC1 Assigned To: srinatar New Comment: I had a chance to compile and test PHP5.2.11RC1 under Linux this morning (Ubuntu Jaunty, Apache 2.2.11 from repositories), and these warnings do not appear, however I noticed another problem. Although the SSL+async connection is successful and data is returned under Linux, the socket is not actually opened asynchonously. The script blocks until the socket has finished opening, exactly as it does without the ASYNC flag. This is also true under Windows, for the first run -- after that, of course, it returns the errors posted above. Previous Comments: [2009-08-21 01:15:44] srina...@php.net this issue seems to be happening when this script is executed more than once and also seems to be happening only on windows. [2009-08-19 13:52:18] frase at cs dot wisc dot edu Description: stream_socket_client() can only open one socket using SSL and the STREAM_CLIENT_ASYNC_CONNECT flag, and then fails every time until the Apache process is restarted. SSL sockets without ASYNC open fine, as do plain TCP sockets with or without ASYNC. Originally reported as an update to bug #48182, which also only affected the combination of SSL+ASYNC, but now reported separately here per srina...@php.net's request. Additionally, the timeout (argument #4 to stream_socket_client()) is not ignored when using ASYNC, contrary to the manual: if set to 0 here, the first warning is "SSL: connection timeout" instead of "SSL: The operation completed successfully." Windows 2000 Professional SP4 Apache 2.2.11 PHP 5.2.11RC1-Win32-VC6-x86 (threadsafe binary from http://windows.php.net/qa/) configured as an Apache module with php_openssl.dll and libeay32.dll+ssleay.dll v0.9.8k Reproduce code: --- http://bugs.php.net/?id=49295&edit=1
#48182 [Com]: asynchronous socket connection over ssl fails entirely
ID: 48182 Comment by: frase at cs dot wisc dot edu Reported By: frase at cs dot wisc dot edu Status: Feedback Bug Type: OpenSSL related Operating System: * PHP Version: 5.2.11RC1 Assigned To: srinatar New Comment: It is exactly the same script that produces this new error for me on Windows. However as you request, I have opened a new bug#49295 for this behavior. Previous Comments: [2009-08-19 03:35:30] srina...@php.net i was able to verify this successfully by compiling php 5.2.11 rc1 (did not use the rc1 candidate build) on windows and run the below script that you attached as part of this bug report. now, if you have a different test script that is causing this issue then i would suggest that you should better file a separate bug and attach this new test case. this way , we can track different issues separately rather than overloading this bug. [2009-08-18 13:40:41] frase at cs dot wisc dot edu The new problem could be unrelated, it is definitely different behavior than before. I've reported it here only because it still only affects ssl:// socket connections opened asynchronously -- tcp sockets open fine (both sync and async), and ssl sockets open fine synchronously. Also, I have a new clue. The very first attempt (ssl+async) on a freshly booted Apache server works fine. It is only on the second and subsequent attempts that the new warnings appear and the socket won't open. When I restart Apache, it works one more time. This is Windows 2000 Professional SP4, Apache 2.2.11, with the posted PHP 5.2.11RC1-Win32-VC6 binary (threadsafe, and apparently including OpenSSL 0.9.8k) configured as an Apache module (not CGI). Hope that helps. [2009-08-18 02:11:12] srina...@php.net thanks for verifying it. let me try this again with php 5.2.11rc1 and see why it is happening (again). [2009-08-14 13:56:38] frase at cs dot wisc dot edu To clarify, I tested the posted patch by recompiling 5.3.0 on Ubuntu Linux, and the fix worked. I was not able to test the patch in 5.2.10 on Windows as I have no suitable build environment. The posted 5.2.11RC1 binaries (under Apache 2.2.11) now exhibit this new problem. [2009-08-14 13:49:53] frase at cs dot wisc dot edu I'm re-opening this bug as the fix appears not to work in 5.2.11RC1. With the same testing code as in the original report, when connecting synchronously, all is well. But when connecting asynchronously I get these warnings: Warning: stream_socket_client() [function.stream-socket-client]: SSL: The operation completed successfully. in test-async-ssl.php on line 14 Warning: stream_socket_client() [function.stream-socket-client]: Failed to enable crypto in test-async-ssl.php on line 14 Warning: stream_socket_client() [function.stream-socket-client]: unable to connect to ssl://91.189.90.211:443 (Unknown error) in test-async-ssl.php on line 14 Line 14 is of course the stream_socket_client() call. Additionally, after these warnings, $errno contains 10035 and $errstr 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/48182 -- Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#49295 [NEW]: stream_socket_client() fails on SSL+async
From: frase at cs dot wisc dot edu Operating system: Win 2000 Pro SP4 PHP version: 5.2.11RC1 PHP Bug Type: OpenSSL related Bug description: stream_socket_client() fails on SSL+async Description: stream_socket_client() can only open one socket using SSL and the STREAM_CLIENT_ASYNC_CONNECT flag, and then fails every time until the Apache process is restarted. SSL sockets without ASYNC open fine, as do plain TCP sockets with or without ASYNC. Originally reported as an update to bug #48182, which also only affected the combination of SSL+ASYNC, but now reported separately here per srina...@php.net's request. Additionally, the timeout (argument #4 to stream_socket_client()) is not ignored when using ASYNC, contrary to the manual: if set to 0 here, the first warning is "SSL: connection timeout" instead of "SSL: The operation completed successfully." Windows 2000 Professional SP4 Apache 2.2.11 PHP 5.2.11RC1-Win32-VC6-x86 (threadsafe binary from http://windows.php.net/qa/) configured as an Apache module with php_openssl.dll and libeay32.dll+ssleay.dll v0.9.8k Reproduce code: --- http://bugs.php.net/?id=49295&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49295&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49295&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49295&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49295&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49295&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49295&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49295&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49295&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49295&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49295&r=support Expected behavior: http://bugs.php.net/fix.php?id=49295&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49295&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49295&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49295&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49295&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49295&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49295&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49295&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49295&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49295&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49295&r=mysqlcfg
#48182 [Com]: asynchronous socket connection over ssl fails entirely
ID: 48182 Comment by: frase at cs dot wisc dot edu Reported By: frase at cs dot wisc dot edu Status: Assigned Bug Type: OpenSSL related Operating System: * PHP Version: 5.2.11RC1 Assigned To: srinatar New Comment: The new problem could be unrelated, it is definitely different behavior than before. I've reported it here only because it still only affects ssl:// socket connections opened asynchronously -- tcp sockets open fine (both sync and async), and ssl sockets open fine synchronously. Also, I have a new clue. The very first attempt (ssl+async) on a freshly booted Apache server works fine. It is only on the second and subsequent attempts that the new warnings appear and the socket won't open. When I restart Apache, it works one more time. This is Windows 2000 Professional SP4, Apache 2.2.11, with the posted PHP 5.2.11RC1-Win32-VC6 binary (threadsafe, and apparently including OpenSSL 0.9.8k) configured as an Apache module (not CGI). Hope that helps. Previous Comments: [2009-08-18 02:11:12] srina...@php.net thanks for verifying it. let me try this again with php 5.2.11rc1 and see why it is happening (again). [2009-08-14 13:56:38] frase at cs dot wisc dot edu To clarify, I tested the posted patch by recompiling 5.3.0 on Ubuntu Linux, and the fix worked. I was not able to test the patch in 5.2.10 on Windows as I have no suitable build environment. The posted 5.2.11RC1 binaries (under Apache 2.2.11) now exhibit this new problem. [2009-08-14 13:49:53] frase at cs dot wisc dot edu I'm re-opening this bug as the fix appears not to work in 5.2.11RC1. With the same testing code as in the original report, when connecting synchronously, all is well. But when connecting asynchronously I get these warnings: Warning: stream_socket_client() [function.stream-socket-client]: SSL: The operation completed successfully. in test-async-ssl.php on line 14 Warning: stream_socket_client() [function.stream-socket-client]: Failed to enable crypto in test-async-ssl.php on line 14 Warning: stream_socket_client() [function.stream-socket-client]: unable to connect to ssl://91.189.90.211:443 (Unknown error) in test-async-ssl.php on line 14 Line 14 is of course the stream_socket_client() call. Additionally, after these warnings, $errno contains 10035 and $errstr is empty. [2009-07-28 19:34:15] srina...@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. Committed revision 286465. [2009-07-10 13:38:01] frase at cs dot wisc dot edu The supplied patch does fix the problem in 5.3.0 on Linux; I have no Windows build environment so I can't test it there but can't see why it wouldn't also work. Since the patch was to OpenSSL I've changed the category back. Many thanks! 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/48182 -- Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#48182 [Com]: asynchronous socket connection over ssl fails entirely
ID: 48182
Comment by: frase at cs dot wisc dot edu
Reported By: frase at cs dot wisc dot edu
Status: Open
Bug Type: OpenSSL related
Operating System: *
PHP Version: 5.2.11RC1
Assigned To: srinatar
New Comment:
To clarify, I tested the posted patch by recompiling 5.3.0 on Ubuntu
Linux, and the fix worked. I was not able to test the patch in 5.2.10
on Windows as I have no suitable build environment. The posted
5.2.11RC1 binaries (under Apache 2.2.11) now exhibit this new problem.
Previous Comments:
[2009-08-14 13:49:53] frase at cs dot wisc dot edu
I'm re-opening this bug as the fix appears not to work in 5.2.11RC1.
With the same testing code as in the original report, when connecting
synchronously, all is well. But when connecting asynchronously I get
these warnings:
Warning: stream_socket_client() [function.stream-socket-client]: SSL:
The operation completed successfully. in test-async-ssl.php on line 14
Warning: stream_socket_client() [function.stream-socket-client]: Failed
to enable crypto in test-async-ssl.php on line 14
Warning: stream_socket_client() [function.stream-socket-client]: unable
to connect to ssl://91.189.90.211:443 (Unknown error) in
test-async-ssl.php on line 14
Line 14 is of course the stream_socket_client() call. Additionally,
after these warnings, $errno contains 10035 and $errstr is empty.
[2009-07-28 19:34:15] srina...@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.
Committed revision 286465.
[2009-07-10 13:38:01] frase at cs dot wisc dot edu
The supplied patch does fix the problem in 5.3.0 on Linux; I have no
Windows build environment so I can't test it there but can't see why it
wouldn't also work. Since the patch was to OpenSSL I've changed the
category back.
Many thanks!
[2009-07-09 21:53:03] sriram dot natarajan at gmail dot com
better still, here is the patch (more readable format)
http://pastebin.org/805
[2009-07-09 21:47:44] sriram dot natarajan at gmail dot com
thanks for your patience.
here is a patch that should address your issue. to apply this patch,
save the above text into a file and run
--- ext/openssl/xp_ssl.c.ORIG Thu Jul 9 12:20:44 2009
+++ ext/openssl/xp_ssl.cThu Jul 9 12:29:18 2009
@@ -672,7 +672,11 @@
* we notice that the connect
has actually been established */
php_stream_socket_ops.set_option(stream, option, value, ptrparam
TSRMLS_CC);
- if (xparam->outputs.returncode
== 0 && sslsock->enable_on_connect) {
+ if
((sslsock->enable_on_connect) &&
+
((xparam->outputs.returncode == 0) ||
+(xparam->op ==
STREAM_XPORT_OP_CONNECT_ASYNC && xparam->outputs.returncode == 1 &&
+
xparam->outputs.error_code == EINPROGRESS)))
+ {
if
(php_stream_xport_crypto_setup(stream, sslsock->method, NULL TSRMLS_CC)
< 0 ||
php_stream_xport_crypto_enable(stream, 1 TSRMLS_CC) < 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Failed to enable crypto");
- download and unzip the latest php 5.3snapshot from
http://snaps.php.net
- cd ; patch -p0 -d . <
now, you can run make and should be able to test it.
i will wait for some one to review this patch . hopefully, should
happen before next release :-)
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/48182
--
Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#48182 [Csd->Opn]: asynchronous socket connection over ssl fails entirely
ID: 48182
User updated by: frase at cs dot wisc dot edu
-Summary: ssl handshake fails during asynchronous socket
connection
Reported By: frase at cs dot wisc dot edu
-Status: Closed
+Status: Open
Bug Type: OpenSSL related
Operating System: *
-PHP Version: 5.2.10, 5.3.0
+PHP Version: 5.2.11RC1
Assigned To: srinatar
New Comment:
I'm re-opening this bug as the fix appears not to work in 5.2.11RC1.
With the same testing code as in the original report, when connecting
synchronously, all is well. But when connecting asynchronously I get
these warnings:
Warning: stream_socket_client() [function.stream-socket-client]: SSL:
The operation completed successfully. in test-async-ssl.php on line 14
Warning: stream_socket_client() [function.stream-socket-client]: Failed
to enable crypto in test-async-ssl.php on line 14
Warning: stream_socket_client() [function.stream-socket-client]: unable
to connect to ssl://91.189.90.211:443 (Unknown error) in
test-async-ssl.php on line 14
Line 14 is of course the stream_socket_client() call. Additionally,
after these warnings, $errno contains 10035 and $errstr is empty.
Previous Comments:
[2009-07-28 19:34:15] srina...@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.
Committed revision 286465.
[2009-07-10 13:38:01] frase at cs dot wisc dot edu
The supplied patch does fix the problem in 5.3.0 on Linux; I have no
Windows build environment so I can't test it there but can't see why it
wouldn't also work. Since the patch was to OpenSSL I've changed the
category back.
Many thanks!
[2009-07-09 21:53:03] sriram dot natarajan at gmail dot com
better still, here is the patch (more readable format)
http://pastebin.org/805
[2009-07-09 21:47:44] sriram dot natarajan at gmail dot com
thanks for your patience.
here is a patch that should address your issue. to apply this patch,
save the above text into a file and run
--- ext/openssl/xp_ssl.c.ORIG Thu Jul 9 12:20:44 2009
+++ ext/openssl/xp_ssl.cThu Jul 9 12:29:18 2009
@@ -672,7 +672,11 @@
* we notice that the connect
has actually been established */
php_stream_socket_ops.set_option(stream, option, value, ptrparam
TSRMLS_CC);
- if (xparam->outputs.returncode
== 0 && sslsock->enable_on_connect) {
+ if
((sslsock->enable_on_connect) &&
+
((xparam->outputs.returncode == 0) ||
+(xparam->op ==
STREAM_XPORT_OP_CONNECT_ASYNC && xparam->outputs.returncode == 1 &&
+
xparam->outputs.error_code == EINPROGRESS)))
+ {
if
(php_stream_xport_crypto_setup(stream, sslsock->method, NULL TSRMLS_CC)
< 0 ||
php_stream_xport_crypto_enable(stream, 1 TSRMLS_CC) < 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Failed to enable crypto");
- download and unzip the latest php 5.3snapshot from
http://snaps.php.net
- cd ; patch -p0 -d . <
now, you can run make and should be able to test it.
i will wait for some one to review this patch . hopefully, should
happen before next release :-)
--------------------
[2009-07-01 16:28:14] frase at cs dot wisc dot edu
This bug remains also in 5.2.10.
Let's try a new summary and changing the category to "Sockets", maybe
it will get someone's attention.
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/48182
--
Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#48182 [Opn]: ssl handshake fails during asynchronous socket connection
ID: 48182
User updated by: frase at cs dot wisc dot edu
Reported By: frase at cs dot wisc dot edu
Status: Open
-Bug Type: Sockets related
+Bug Type: OpenSSL related
Operating System: *
PHP Version: 5.2.10, 5.3.0
New Comment:
The supplied patch does fix the problem in 5.3.0 on Linux; I have no
Windows build environment so I can't test it there but can't see why it
wouldn't also work. Since the patch was to OpenSSL I've changed the
category back.
Many thanks!
Previous Comments:
[2009-07-09 21:53:03] sriram dot natarajan at gmail dot com
better still, here is the patch (more readable format)
http://pastebin.org/805
[2009-07-09 21:47:44] sriram dot natarajan at gmail dot com
thanks for your patience.
here is a patch that should address your issue. to apply this patch,
save the above text into a file and run
--- ext/openssl/xp_ssl.c.ORIG Thu Jul 9 12:20:44 2009
+++ ext/openssl/xp_ssl.cThu Jul 9 12:29:18 2009
@@ -672,7 +672,11 @@
* we notice that the connect
has actually been established */
php_stream_socket_ops.set_option(stream, option, value, ptrparam
TSRMLS_CC);
- if (xparam->outputs.returncode
== 0 && sslsock->enable_on_connect) {
+ if
((sslsock->enable_on_connect) &&
+
((xparam->outputs.returncode == 0) ||
+(xparam->op ==
STREAM_XPORT_OP_CONNECT_ASYNC && xparam->outputs.returncode == 1 &&
+
xparam->outputs.error_code == EINPROGRESS)))
+ {
if
(php_stream_xport_crypto_setup(stream, sslsock->method, NULL TSRMLS_CC)
< 0 ||
php_stream_xport_crypto_enable(stream, 1 TSRMLS_CC) < 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Failed to enable crypto");
- download and unzip the latest php 5.3snapshot from
http://snaps.php.net
- cd ; patch -p0 -d . <
now, you can run make and should be able to test it.
i will wait for some one to review this patch . hopefully, should
happen before next release :-)
------------------------
[2009-07-01 16:28:14] frase at cs dot wisc dot edu
This bug remains also in 5.2.10.
Let's try a new summary and changing the category to "Sockets", maybe
it will get someone's attention.
------------
[2009-06-30 14:28:01] frase at cs dot wisc dot edu
This bug remains in 5.3.0 final.
------------
[2009-06-19 13:38:53] frase at cs dot wisc dot edu
This bug is still present in 5.3.0 as of RC4, and also affects Linux
hosts.
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/48182
--
Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#48182 [Opn]: ssl handshake fails during asynchronous socket connection
ID: 48182 User updated by: frase at cs dot wisc dot edu -Summary: stream_socket_client(ssl:// ... STREAM_CLIENT_ASYNC_CONNECT) fails Reported By: frase at cs dot wisc dot edu Status: Open -Bug Type: OpenSSL related +Bug Type: Sockets related Operating System: * -PHP Version: 5.2.9, 5.3.0RC4 +PHP Version: 5.2.10, 5.3.0 New Comment: This bug remains also in 5.2.10. Let's try a new summary and changing the category to "Sockets", maybe it will get someone's attention. Previous Comments: [2009-06-30 14:28:01] frase at cs dot wisc dot edu This bug remains in 5.3.0 final. [2009-06-19 13:38:53] frase at cs dot wisc dot edu This bug is still present in 5.3.0 as of RC4, and also affects Linux hosts. [2009-06-08 14:14:30] frase at cs dot wisc dot edu Hate to bump my own bug, but it's been a month. Nobody's concerned that ssl:// streams + ASYNC_CONNECT has this silent failure? And that there's a chance it's causing data intended for ssl:// to instead be transmitted in plaintext? ------------ [2009-05-07 16:23:49] frase at cs dot wisc dot edu Description: When opening a socket connection with stream_socket_client() and the ssl:// wrapper, the connect-asynchronously flag (STREAM_CLIENT_ASYNC_CONNECT) causes ssl encryption to fail. Connecting asynchronously with tcp:// works, as does connecting synchronously with ssl://. If I remove the ASYNC flag from the example code, I get normal HTTP headers and HTML content. If I leave the flag but change the scheme to tcp:// and port to 80, launchpad.net gives me a normal HTTP/HTML redirect to the encrypted url (https://...). But as written, I instead get an error from the server indicating that my request could not be decrypted via SSL, and no HTTP headers whatsoever. I'm not sure if this bug is more properly "OpenSSL related" or "Sockets related", so I've guessed the former. But I wonder if maybe stream_select() considers the socket writable once it's opened, but before the SSL handshake is complete; that might cause this code to fwrite() too early, possibly going out plaintext. Then I suppose the solution is for stream_select() to not return ssl:// sockets until the handshake is complete, in addition to simply being opened. Reproduce code: --- http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en" dir="ltr"> Launchpad ... etc Actual result: -- An HTML source error message: 400 Bad Request Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Hint: https://launchpad.net/";>https://launchpad.net/ Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g Server at launchpad.net Port 443 -- Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#48182 [Com]: stream_socket_client(ssl:// ... STREAM_CLIENT_ASYNC_CONNECT) fails
ID: 48182 Comment by: frase at cs dot wisc dot edu Reported By: frase at cs dot wisc dot edu Status: Open Bug Type: OpenSSL related Operating System: * PHP Version: 5.2.9, 5.3.0RC4 New Comment: This bug remains in 5.3.0 final. Previous Comments: [2009-06-19 13:38:53] frase at cs dot wisc dot edu This bug is still present in 5.3.0 as of RC4, and also affects Linux hosts. [2009-06-08 14:14:30] frase at cs dot wisc dot edu Hate to bump my own bug, but it's been a month. Nobody's concerned that ssl:// streams + ASYNC_CONNECT has this silent failure? And that there's a chance it's causing data intended for ssl:// to instead be transmitted in plaintext? [2009-05-07 16:23:49] frase at cs dot wisc dot edu Description: When opening a socket connection with stream_socket_client() and the ssl:// wrapper, the connect-asynchronously flag (STREAM_CLIENT_ASYNC_CONNECT) causes ssl encryption to fail. Connecting asynchronously with tcp:// works, as does connecting synchronously with ssl://. If I remove the ASYNC flag from the example code, I get normal HTTP headers and HTML content. If I leave the flag but change the scheme to tcp:// and port to 80, launchpad.net gives me a normal HTTP/HTML redirect to the encrypted url (https://...). But as written, I instead get an error from the server indicating that my request could not be decrypted via SSL, and no HTTP headers whatsoever. I'm not sure if this bug is more properly "OpenSSL related" or "Sockets related", so I've guessed the former. But I wonder if maybe stream_select() considers the socket writable once it's opened, but before the SSL handshake is complete; that might cause this code to fwrite() too early, possibly going out plaintext. Then I suppose the solution is for stream_select() to not return ssl:// sockets until the handshake is complete, in addition to simply being opened. Reproduce code: --- http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en" dir="ltr"> Launchpad ... etc Actual result: -- An HTML source error message: 400 Bad Request Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Hint: https://launchpad.net/";>https://launchpad.net/ Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g Server at launchpad.net Port 443 -- Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#48539 [Opn]: pdo_dblib fails to connect, throws empty PDOException "SQLSTATE[] (null)"
ID: 48539
User updated by: frase at cs dot wisc dot edu
Reported By: frase at cs dot wisc dot edu
Status: Open
Bug Type: PDO related
Operating System: Ubuntu 9.04 Jaunty
-PHP Version: 5.3.0RC3
+PHP Version: 5.3.0RC4
New Comment:
This problem remains in RC4.
Previous Comments:
[2009-06-12 19:59:51] frase at cs dot wisc dot edu
Description:
I have compiled PHP 5.3.0RC3 from source as a module for Apache 2.2.11,
and I cannot open a connection to an MSSQL server using PDO's dblib
(FreeTDS) driver. Instead, I get a PDOException with no SQLSTATE code
or message.
The sample code below works in PHP 5.2.6 (as packaged for Jaunty).
Non-PDO MSSQL connections work ("mssql_connect()").
PDO MySQL connections also work ("PDO('mysql:...')").
"phpinfo()" confirms that the PDO extension is loaded, with dblib and
mysql drivers. The pdo_dblib section confirms that it is using
FreeTDS.
There is no change by compiling the extensions (mssql, pdo, pdo_dblib)
as external shared modules or built-in to libphp5.so.
Reproduce code:
---
query('select count(1) from mytable') or die ("failed
to query database");
echo "got ".($result->fetchColumn())." rows\n";
$result->closeCursor() or die("failed to free resultset");
$db = null;
} catch (Exception $e) {
echo $e;
}
Expected result:
got (some-number) rows
Actual result:
--
exception 'PDOException' with message 'SQLSTATE[] (null) (severity 0)'
in /home/user/htdocs/test-pdo.php:5
Stack trace:
#0 /home/user/htdocs/test-pdo.php(5):
PDO->__construct('dblib:host=myho...', 'myuser', 'mypass')
#1 {main}
--
Edit this bug report at http://bugs.php.net/?id=48539&edit=1
#48182 [Opn]: stream_socket_client(ssl:// ... STREAM_CLIENT_ASYNC_CONNECT) fails
ID: 48182 User updated by: frase at cs dot wisc dot edu Reported By: frase at cs dot wisc dot edu Status: Open Bug Type: OpenSSL related -Operating System: Windows 2000 Pro SP4 +Operating System: all -PHP Version: 5.2.9 +PHP Version: 5.2.9, 5.3.0RC4 New Comment: This bug is still present in 5.3.0 as of RC4, and also affects Linux hosts. Previous Comments: [2009-06-08 14:14:30] frase at cs dot wisc dot edu Hate to bump my own bug, but it's been a month. Nobody's concerned that ssl:// streams + ASYNC_CONNECT has this silent failure? And that there's a chance it's causing data intended for ssl:// to instead be transmitted in plaintext? [2009-05-07 16:23:49] frase at cs dot wisc dot edu Description: When opening a socket connection with stream_socket_client() and the ssl:// wrapper, the connect-asynchronously flag (STREAM_CLIENT_ASYNC_CONNECT) causes ssl encryption to fail. Connecting asynchronously with tcp:// works, as does connecting synchronously with ssl://. If I remove the ASYNC flag from the example code, I get normal HTTP headers and HTML content. If I leave the flag but change the scheme to tcp:// and port to 80, launchpad.net gives me a normal HTTP/HTML redirect to the encrypted url (https://...). But as written, I instead get an error from the server indicating that my request could not be decrypted via SSL, and no HTTP headers whatsoever. I'm not sure if this bug is more properly "OpenSSL related" or "Sockets related", so I've guessed the former. But I wonder if maybe stream_select() considers the socket writable once it's opened, but before the SSL handshake is complete; that might cause this code to fwrite() too early, possibly going out plaintext. Then I suppose the solution is for stream_select() to not return ssl:// sockets until the handshake is complete, in addition to simply being opened. Reproduce code: --- http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en" dir="ltr"> Launchpad ... etc Actual result: -- An HTML source error message: 400 Bad Request Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Hint: https://launchpad.net/";>https://launchpad.net/ Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g Server at launchpad.net Port 443 -- Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#48539 [NEW]: pdo_dblib fails to connect, throws empty PDOException "SQLSTATE[] (null)"
From: frase at cs dot wisc dot edu
Operating system: Ubuntu 9.04 Jaunty
PHP version: 5.3.0RC3
PHP Bug Type: PDO related
Bug description: pdo_dblib fails to connect, throws empty PDOException
"SQLSTATE[] (null)"
Description:
I have compiled PHP 5.3.0RC3 from source as a module for Apache 2.2.11,
and I cannot open a connection to an MSSQL server using PDO's dblib
(FreeTDS) driver. Instead, I get a PDOException with no SQLSTATE code or
message.
The sample code below works in PHP 5.2.6 (as packaged for Jaunty).
Non-PDO MSSQL connections work ("mssql_connect()").
PDO MySQL connections also work ("PDO('mysql:...')").
"phpinfo()" confirms that the PDO extension is loaded, with dblib and
mysql drivers. The pdo_dblib section confirms that it is using FreeTDS.
There is no change by compiling the extensions (mssql, pdo, pdo_dblib) as
external shared modules or built-in to libphp5.so.
Reproduce code:
---
query('select count(1) from mytable') or die ("failed to
query database");
echo "got ".($result->fetchColumn())." rows\n";
$result->closeCursor() or die("failed to free resultset");
$db = null;
} catch (Exception $e) {
echo $e;
}
Expected result:
got (some-number) rows
Actual result:
--
exception 'PDOException' with message 'SQLSTATE[] (null) (severity 0)' in
/home/user/htdocs/test-pdo.php:5
Stack trace:
#0 /home/user/htdocs/test-pdo.php(5):
PDO->__construct('dblib:host=myho...', 'myuser', 'mypass')
#1 {main}
--
Edit bug report at http://bugs.php.net/?id=48539&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48539&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48539&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48539&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48539&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48539&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48539&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48539&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48539&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48539&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48539&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48539&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48539&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48539&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48539&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48539&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48539&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48539&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48539&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48539&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48539&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48539&r=mysqlcfg
#48182 [Com]: stream_socket_client(ssl:// ... STREAM_CLIENT_ASYNC_CONNECT) fails
ID: 48182 Comment by: frase at cs dot wisc dot edu Reported By: frase at cs dot wisc dot edu Status: Open Bug Type: OpenSSL related Operating System: Windows 2000 Pro SP4 PHP Version: 5.2.9 New Comment: Hate to bump my own bug, but it's been a month. Nobody's concerned that ssl:// streams + ASYNC_CONNECT has this silent failure? And that there's a chance it's causing data intended for ssl:// to instead be transmitted in plaintext? Previous Comments: [2009-05-07 16:23:49] frase at cs dot wisc dot edu Description: When opening a socket connection with stream_socket_client() and the ssl:// wrapper, the connect-asynchronously flag (STREAM_CLIENT_ASYNC_CONNECT) causes ssl encryption to fail. Connecting asynchronously with tcp:// works, as does connecting synchronously with ssl://. If I remove the ASYNC flag from the example code, I get normal HTTP headers and HTML content. If I leave the flag but change the scheme to tcp:// and port to 80, launchpad.net gives me a normal HTTP/HTML redirect to the encrypted url (https://...). But as written, I instead get an error from the server indicating that my request could not be decrypted via SSL, and no HTTP headers whatsoever. I'm not sure if this bug is more properly "OpenSSL related" or "Sockets related", so I've guessed the former. But I wonder if maybe stream_select() considers the socket writable once it's opened, but before the SSL handshake is complete; that might cause this code to fwrite() too early, possibly going out plaintext. Then I suppose the solution is for stream_select() to not return ssl:// sockets until the handshake is complete, in addition to simply being opened. Reproduce code: --- http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en" dir="ltr"> Launchpad ... etc Actual result: -- An HTML source error message: 400 Bad Request Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Hint: https://launchpad.net/";>https://launchpad.net/ Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g Server at launchpad.net Port 443 -- Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#48182 [NEW]: stream_socket_client(ssl:// ... STREAM_CLIENT_ASYNC_CONNECT) fails
From: frase at cs dot wisc dot edu Operating system: Windows 2000 Pro SP4 PHP version: 5.2.9 PHP Bug Type: OpenSSL related Bug description: stream_socket_client(ssl:// ... STREAM_CLIENT_ASYNC_CONNECT) fails Description: When opening a socket connection with stream_socket_client() and the ssl:// wrapper, the connect-asynchronously flag (STREAM_CLIENT_ASYNC_CONNECT) causes ssl encryption to fail. Connecting asynchronously with tcp:// works, as does connecting synchronously with ssl://. If I remove the ASYNC flag from the example code, I get normal HTTP headers and HTML content. If I leave the flag but change the scheme to tcp:// and port to 80, launchpad.net gives me a normal HTTP/HTML redirect to the encrypted url (https://...). But as written, I instead get an error from the server indicating that my request could not be decrypted via SSL, and no HTTP headers whatsoever. I'm not sure if this bug is more properly "OpenSSL related" or "Sockets related", so I've guessed the former. But I wonder if maybe stream_select() considers the socket writable once it's opened, but before the SSL handshake is complete; that might cause this code to fwrite() too early, possibly going out plaintext. Then I suppose the solution is for stream_select() to not return ssl:// sockets until the handshake is complete, in addition to simply being opened. Reproduce code: --- http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en" dir="ltr"> Launchpad ... etc Actual result: -- An HTML source error message: 400 Bad Request Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Hint: https://launchpad.net/";>https://launchpad.net/ Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g Server at launchpad.net Port 443 -- Edit bug report at http://bugs.php.net/?id=48182&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48182&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48182&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48182&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48182&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48182&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48182&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48182&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48182&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48182&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48182&r=support Expected behavior: http://bugs.php.net/fix.php?id=48182&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48182&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48182&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48182&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48182&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48182&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48182&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48182&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48182&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48182&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48182&r=mysqlcfg
#41712 [Com]: [PATCH] Add CURL Progress Function Callback
ID: 41712
Comment by: frase at cs dot wisc dot edu
Reported By: sdteffen at gmail dot com
Status: Assigned
Bug Type: Feature/Change Request
Operating System: SuSE Linux 10.2
PHP Version: 5CVS-2007-06-16 (CVS)
Assigned To: iliaa
New Comment:
What happened here? A patch was offered for this feature almost two
years ago, and was assigned to the maintainer a week later. The next
six months saw some tweaks and corrections, and yet here we are two
years later with this still languishing in "assigned" limbo, neither
accepted and merged nor rejected and closed.
Ilia? Tony? Bueller?
Previous Comments:
[2009-02-20 09:27:43] php41712 at brainpower dot no-ip dot org
can somewone submit this to the php code as this will help a lot of
users
[2008-02-16 15:00:15] sdteffen at gmail dot com
The last patch is missing the changes to php_curl.h from the previous
patch. A file containing the complete patch with changes for both files
can be found under this URL:
http://sdteffen.de/php/php_curl_progress_callback.patch
[2008-02-06 21:35:33] renatobraga at gmail dot com
Thanks Steffen,
Worked like a charm
[2008-02-06 18:14:12] sdteffen at gmail dot com
I've updated the patch to pass the return value from the callback
function as Renato suggested:
--- php-5.2.5.orig/ext/curl/interface.c 2007-10-13 13:35:35.0
+0200
+++ php-5.2.5.patch/ext/curl/interface.c2008-02-06 18:43:41.0
+0100
@@ -368,6 +368,7 @@
REGISTER_CURL_CONSTANT(CURLOPT_HEADER);
REGISTER_CURL_CONSTANT(CURLOPT_HTTPHEADER);
REGISTER_CURL_CONSTANT(CURLOPT_NOPROGRESS);
+ REGISTER_CURL_CONSTANT(CURLOPT_PROGRESSFUNCTION);
REGISTER_CURL_CONSTANT(CURLOPT_NOBODY);
REGISTER_CURL_CONSTANT(CURLOPT_FAILONERROR);
REGISTER_CURL_CONSTANT(CURLOPT_UPLOAD);
@@ -780,6 +781,87 @@
}
/* }}} */
+/* {{{ curl_progress
+ */
+static size_t curl_progress(void *clientp,
+double dltotal,
+double dlnow,
+double ultotal,
+double ulnow)
+{
+ php_curl *ch = (php_curl *) clientp;
+ php_curl_progress *t = ch->handlers->progress;
+ int length = -1;
+ size_t rval = 0;
+
+#if PHP_CURL_DEBUG
+ fprintf(stderr, "curl_progress() called\n");
+ fprintf(stderr, "clientp = %x, dltotal = %f, dlnow = %f, ultotal =
%f, ulnow = %f\n", clientp, dltotal, dlnow, ultotal, ulnow);
+#endif
+
+ switch (t->method) {
+ case PHP_CURL_USER: {
+ zval **argv[4];
+ zval *zdltotal = NULL;
+ zval *zdlnow = NULL;
+ zval *zultotal = NULL;
+ zval *zulnow = NULL;
+ zval *retval_ptr;
+ int error;
+ zend_fcall_info fci;
+ TSRMLS_FETCH_FROM_CTX(ch->thread_ctx);
+
+ MAKE_STD_ZVAL(zdltotal);
+ MAKE_STD_ZVAL(zdlnow);
+ MAKE_STD_ZVAL(zultotal);
+ MAKE_STD_ZVAL(zulnow);
+
+ ZVAL_LONG(zdltotal, dltotal);
+ ZVAL_LONG(zdlnow, dlnow);
+ ZVAL_LONG(zultotal, ultotal);
+ ZVAL_LONG(zulnow, ulnow);
+
+ argv[0] = &zdltotal;
+ argv[1] = &zdlnow;
+ argv[2] = &zultotal;
+ argv[3] = &zulnow;
+
+ fci.size = sizeof(fci);
+ fci.function_table = EG(function_table);
+ fci.function_name = t->func_name;
+ fci.object_pp = NULL;
+ fci.retval_ptr_ptr = &retval_ptr;
+ fci.param_count = 4;
+ fci.params = argv;
+ fci.no_separation = 0;
+ fci.symbol_table = NULL;
+
+ ch->in_callback = 1;
+ error = zend_call_function(&fci, &t->fci_cache
TSRMLS_CC);
+ ch->in_callback = 0;
+ if (error == FAILURE) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING,
"Cannot call the
CURLOPT_READFUNCTION");
+ length = -1;
+ } else if (retval_ptr) {
+ if (Z_TYPE_P
#34972 [Com]: STDIN won't allow nonblocking.
ID: 34972
Comment by: frase at cs dot wisc dot edu
Reported By: VJTD3 at VJTD3 dot com
Status: Assigned
Bug Type: Streams related
Operating System: win32 only
PHP Version: 5.2CVS-2008-07-15
Assigned To: pajoye
New Comment:
I'm having the same trouble.
With php-5.3.0-beta1 on Linux it works fine, both on STDIN and on
fopen('/dev/ttyS0'). stream_set_blocking() returns true,
stream_get_meta_data() confirms, and the stream behaves as if
non-blocking.
But with php-5.2.9 on Windows 2000 it doesn't work for either STDIN or
the serial port (COM1 instead of /dev/ttyS0). stream_set_blocking()
returns false, stream_get_meta_data() shows blocking, and the streams do
in fact block. I also tried stream_set_timeout() with a tiny value, to
simulate the effect, but that also returns false and doesn't work.
Previous Comments:
[2008-10-24 16:11:54] j...@php.net
Assigned to the windows port maintainer.
[2008-03-15 10:57:09] VJTD3 at VJTD3 dot com
on *nix it seems to be solved.
easy way to test:
php -r "stream_set_blocking(STDIN, FALSE);echo fread(STDIN, 10);"
on *nix it instantly exits. (correct behavior)
on windows it will hang for input. (incorrect behavior, it's ignoring
the non blocking setting.)
tested on 5.2.5
[2007-08-19 20:51:34] donnyk at gmail dot com
i also have the same problem, i've tried the latest snapshot on windows
to no avail. It works on my linux systems however.
[2007-08-10 13:01:48] VJTD3 at VJTD3 dot com
notice how it just sits there? (blocking) it should exit instantly with
a null echo. (same as a tcp connection where if you just do a read that
is too fast with nonblocking it never gets a chance to fetch the data.)
what is happening is that php is blocking waiting for input
(specifically enter (line ending))
problem:
if you are echoing debug information and want to use key functionality
in tandem you can't because everything is blocked till you hit enter.
[2006-03-27 14:12:28] VJTD3 at VJTD3 dot com
error in last message, "stream_select()" was ment.
code using "stream_select()" that still blocks:
data: '.(strlen(@$data4) ? $data4 :
'empty')."\n";
unset($data4);
sleep('1');
}
?>
the second you type/click a arrow key/anything it goes into blocking
mode again.
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/34972
--
Edit this bug report at http://bugs.php.net/?id=34972&edit=1
#44942 [Com]: exec() hangs apache
ID: 44942
Comment by: frase at cs dot wisc dot edu
Reported By: inqualab1985 at gmail dot com
Status: No Feedback
Bug Type: Program Execution
Operating System: Windows 2000 SP4
PHP Version: 5.2.5
New Comment:
This is happening to me as well, PHP 5.2.8, Apache 2.2.11, Windows 2000
Pro SP4.
However, it only seems to happen when PHP is configured as an Apache
module (php5apache2_2.dll); when I configure it as CGI, it works fine.
I also have anecdotal evidence that it's related somehow to other
sockets being open on the system. In my case, we have a VB (compiled)
application with an embedded IE control, and also opens the serial port
to communicate with some hardware. If that hardware is plugged in (and
PHP is loaded as a module), then our scripts hang at 'exec("ping -n 1
somehost")'. If I unplug the hardware (so the serial port can't be
opened), it works.
Previous Comments:
[2009-02-17 10:12:38] russell_anam at hotmail dot com
I can indeed confirm that this bug exists in the latest PHP version
(PHP 5.2.8). exec() would randomly hang the Apache and the only solution
was to restart the whole server (service restart did not help). I can
also confirm that vlabella's solution INDEED worked for us. Since this
workaround works I think it's safe to say this is indeed a PHP bug that
needs to be fixed ASAP.
[2009-01-29 18:21:30] rolinger1 at hotmail dot com
I came across this article searching for a similar problem. I am using
Perl 5.10 though but am having the same issue with Apache 2.2. That
being said, I believe the issues are the same and that the problem is
with Apache and not php or perl.
With Perl I do a backtick call and Apache's CGI hangs. The windows
system processes shows 1 cmd running and 1 perl app running for each
time I click on the called web script.
Perl call:
@files = `dir ../configs /0:D /A:-D` ;
Somehow, apache uses the backtick command to launch a "cmd" console
process which in turn executes the system call "dir..."
I say the Apache CGI hangs because other PHP scripts (that don't do
system calls) all still seem to work. But after the first CGI hang, all
other Perl calls hang - even scripts that don't have system calls in
them. Scripts with system calls load another pair of cmd/perl processes
and return no data, scripts without system calls loads another perl
process but does return data.
After the initial hang though, all related processes (cmd or perl)
remain in memory and eventually Apache just hangs altogether. And when
that happens we are forced to do a system reboot - simply doing a
service restart has won't work.
[2009-01-15 16:54:54] bill at sammer dot com
session_write_close fixes it for me too. Thanks vlabella!
[2008-12-04 04:35:44] dominic dot manley at det dot wa dot edu dot au
Big thanks to vlabella who led us to a work-around. This is one VERY
frustrating bug to track down!
We have an Apache/PHP 5.2.3/Win2003 setup and concurrent calls to a
script that exec()-ed the same command-line .exe caused the process to
get caught up on the server. Apache wouldn't let go of it and the only
way to kill the process and get the site/sometimes whole server back was
to restart Apache.
I never would have suspected sessions causing this issue... none of our
investigations led us close to that direction. However, vlabella got it
spot on...
Calling session_write_close() before an exec() (or simply never
initiating session support to start with using session_start()) works
around the issue.
[2008-10-21 09:26:44] neododge at free dot fr
The same problem happens for me on PHP 5.2.6 / Apache 2.2.9, Apache
won't run any PHP after I try an exec/passthru/`` -no matter what
command I try. Only way to get PHP back seems to be closing all browser
windows that point to my server and waiting for a while before trying to
use a PHP page again.
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/44942
--
Edit this bug report at http://bugs.php.net/?id=44942&edit=1
#45681 [Com]: namespace visibility
ID: 45681 Comment by: frase at cs dot wisc dot edu Reported By: frase at cs dot wisc dot edu Status: Open Bug Type: Feature/Change Request Operating System: Ubuntu 8.04 Hardy PHP Version: 5.3.0alpha1 New Comment: Also: This would also eliminate the need for class visibility, as mentioned in i.e. Bug #44194. By declaring everything in a class (including the constructor) with the 'namespace' (or lesser) visibility, nothing outside the namespace could instantiate or access it, so the class itself would be effectively invisible outside the namespace. Previous Comments: [2008-08-01 16:25:02] frase at cs dot wisc dot edu Description: When PHP first introduced visibility, it did not yet have namespaces, so the only applicable visibility schemes were related to classes -- members were either global (public), or local to the class (private), possibly including parents and children (protected). But with the addition of namespaces, there is now a need for a visibility scope between public and protected. Developers (like me) will use namespaces to create packages -- collections of classes that are meant to work closely with each other. In this context, it would be very convenient to be able to make members visible to other (unrelated-by-inheritance) classes within the same package (namespace), but hidden from the world outside the package. Since the 'namespace' keyword is currently only allowed on the first line of a file, and therefore could not occur inside a class, I suggest re-using it for this purpose rather than introducing another reserved word. Reproduce code: --- http://bugs.php.net/?id=45681&edit=1
#45681 [NEW]: namespace visibility
From: frase at cs dot wisc dot edu Operating system: Ubuntu 8.04 Hardy PHP version: 5.3.0alpha1 PHP Bug Type: Feature/Change Request Bug description: namespace visibility Description: When PHP first introduced visibility, it did not yet have namespaces, so the only applicable visibility schemes were related to classes -- members were either global (public), or local to the class (private), possibly including parents and children (protected). But with the addition of namespaces, there is now a need for a visibility scope between public and protected. Developers (like me) will use namespaces to create packages -- collections of classes that are meant to work closely with each other. In this context, it would be very convenient to be able to make members visible to other (unrelated-by-inheritance) classes within the same package (namespace), but hidden from the world outside the package. Since the 'namespace' keyword is currently only allowed on the first line of a file, and therefore could not occur inside a class, I suggest re-using it for this purpose rather than introducing another reserved word. Reproduce code: --- http://bugs.php.net/?id=45681&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45681&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45681&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45681&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45681&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45681&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45681&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45681&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45681&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45681&r=support Expected behavior:http://bugs.php.net/fix.php?id=45681&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45681&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45681&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45681&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45681&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45681&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45681&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45681&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45681&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45681&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45681&r=mysqlcfg
#44396 [Bgs]: class compilation notices refer to wrong line number
ID: 44396
User updated by: frase at cs dot wisc dot edu
Reported By: frase at cs dot wisc dot edu
Status: Bogus
Bug Type: Class/Object related
Operating System: Ubuntu 7.10
PHP Version: 5.2.5
New Comment:
Yes, I understand that, and I agree that performance and
constant-definition-order-flexibility are more important than the
accuracy of this error message. As I said, I do not necessarily expect
an immediate patch for this.
However, I would still petition that this report is not "bogus",
because "bogus" implies that there is no mistake to fix. But this
message is, in fact, incorrect, since the undefined constant does not
occur on the line indicated -- the fact that it may not be worth fixing
at this time does not change the validity of that observation.
A "will not fix" or "fix deferred indefinitely" or some such
designation seems more appropriate to me. That way, if some future
change to PHP's internals makes this easier to solve, this report will
remain as a reminder.
Previous Comments:
[2008-03-10 21:07:15] [EMAIL PROTECTED]
Checking this during compilation would require to lookup the constant
during compilation, but we don't enforce the declaration order to allow
more flexible code, yes the message is not perfect but that can't be
changed without major changes which break PHP's current behviour.
--------------------
[2008-03-10 19:18:01] frase at cs dot wisc dot edu
Thanks for the reply. That explains /why/ it happens, but it still is
not ideal behavior; in a very large class, it could take someone a long,
long time to track down the origin of this message, since the line
number attached to it is meaningless.
I suppose I'm not expecting a quick patch to fix this, since it is a
relatively minor problem and I imagine the constant-reference tracking
necessary to solve it would have larger performance implications. But I
thought it worth noting at least, in case some future change to PHP's
internals makes it viable to address this.
[2008-03-10 18:58:57] [EMAIL PROTECTED]
The problem here is that the constant is evaluated just in time, which
means it will only be looked for when you instantiate the class. Your
example may be reduced to :
class A {
public $a = FOOBAR;
}
$a = new A; // Error will be triggered at this point.
Currently the line at which the constant is actually used is not
tracked.
------------------------
[2008-03-10 18:00:58] frase at cs dot wisc dot edu
Description:
If a class definition generates a notice, the line number printed with
the notice corresponds to the first line in which the class is
instantiated, and NOT the line which truly gives rise to the notice.
Reproduce code:
---
class OtherClass {
// etc...
}
class TestClass {
static $linkedClass = OtherClass;
function __construct() {
echo "I am linked to " . self::$linkedClass;
}
}
$obj = new TestClass();
Expected result:
I am linked to OtherClass
Actual result:
--
Notice: Use of undefined constant OtherClass - assumed 'OtherClass' in
test.php on line 10
I am linked to OtherClass
Line 10 does not contain the phrase 'OtherClass' to begin with, as an
undefined constant or otherwise, so the notice is confusing. The line
on which the notice actually arises is line 5, where the class' static
member is incorrectly initialized (it should, in fact, have been a
string).
Disclaimer: The need to have one class refer to another by name, as in
this example, may seem odd but is irrelevant to this bug report (it
arose for me because of a more complicated class inheritance need). I
suspect any notice arising during a class' static member initialization
will have the same wrong line-number; errors other than E_NOTICE might
as well, I haven't taken the time to check exhaustively.
--
Edit this bug report at http://bugs.php.net/?id=44396&edit=1
#44396 [Ver]: class compilation notices refer to wrong line number
ID: 44396
User updated by: frase at cs dot wisc dot edu
Reported By: frase at cs dot wisc dot edu
Status: Verified
Bug Type: Class/Object related
Operating System: Ubuntu 7.10
PHP Version: 5.2.5
New Comment:
Thanks for the reply. That explains /why/ it happens, but it still is
not ideal behavior; in a very large class, it could take someone a long,
long time to track down the origin of this message, since the line
number attached to it is meaningless.
I suppose I'm not expecting a quick patch to fix this, since it is a
relatively minor problem and I imagine the constant-reference tracking
necessary to solve it would have larger performance implications. But I
thought it worth noting at least, in case some future change to PHP's
internals makes it viable to address this.
Previous Comments:
[2008-03-10 18:58:57] [EMAIL PROTECTED]
The problem here is that the constant is evaluated just in time, which
means it will only be looked for when you instantiate the class. Your
example may be reduced to :
class A {
public $a = FOOBAR;
}
$a = new A; // Error will be triggered at this point.
Currently the line at which the constant is actually used is not
tracked.
[2008-03-10 18:00:58] frase at cs dot wisc dot edu
Description:
If a class definition generates a notice, the line number printed with
the notice corresponds to the first line in which the class is
instantiated, and NOT the line which truly gives rise to the notice.
Reproduce code:
---
class OtherClass {
// etc...
}
class TestClass {
static $linkedClass = OtherClass;
function __construct() {
echo "I am linked to " . self::$linkedClass;
}
}
$obj = new TestClass();
Expected result:
I am linked to OtherClass
Actual result:
--
Notice: Use of undefined constant OtherClass - assumed 'OtherClass' in
test.php on line 10
I am linked to OtherClass
Line 10 does not contain the phrase 'OtherClass' to begin with, as an
undefined constant or otherwise, so the notice is confusing. The line
on which the notice actually arises is line 5, where the class' static
member is incorrectly initialized (it should, in fact, have been a
string).
Disclaimer: The need to have one class refer to another by name, as in
this example, may seem odd but is irrelevant to this bug report (it
arose for me because of a more complicated class inheritance need). I
suspect any notice arising during a class' static member initialization
will have the same wrong line-number; errors other than E_NOTICE might
as well, I haven't taken the time to check exhaustively.
--
Edit this bug report at http://bugs.php.net/?id=44396&edit=1
#44396 [NEW]: class compilation notices refer to wrong line number
From: frase at cs dot wisc dot edu
Operating system: Ubuntu 7.10
PHP version: 5.2.5
PHP Bug Type: Class/Object related
Bug description: class compilation notices refer to wrong line number
Description:
If a class definition generates a notice, the line number printed with the
notice corresponds to the first line in which the class is instantiated,
and NOT the line which truly gives rise to the notice.
Reproduce code:
---
class OtherClass {
// etc...
}
class TestClass {
static $linkedClass = OtherClass;
function __construct() {
echo "I am linked to " . self::$linkedClass;
}
}
$obj = new TestClass();
Expected result:
I am linked to OtherClass
Actual result:
--
Notice: Use of undefined constant OtherClass - assumed 'OtherClass' in
test.php on line 10
I am linked to OtherClass
Line 10 does not contain the phrase 'OtherClass' to begin with, as an
undefined constant or otherwise, so the notice is confusing. The line on
which the notice actually arises is line 5, where the class' static member
is incorrectly initialized (it should, in fact, have been a string).
Disclaimer: The need to have one class refer to another by name, as in
this example, may seem odd but is irrelevant to this bug report (it arose
for me because of a more complicated class inheritance need). I suspect
any notice arising during a class' static member initialization will have
the same wrong line-number; errors other than E_NOTICE might as well, I
haven't taken the time to check exhaustively.
--
Edit bug report at http://bugs.php.net/?id=44396&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44396&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44396&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44396&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44396&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44396&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44396&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44396&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44396&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44396&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44396&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44396&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44396&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44396&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44396&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44396&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44396&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44396&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44396&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44396&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44396&r=mysqlcfg
