#32979 [NoF->Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi -Status: No Feedback +Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: Doesn't work with the php5.1-200601172130.tar.gz snapshot nor with 5.1.2. Previous Comments: [2005-11-14 01:00:03] 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". [2005-11-07 00:08:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-28 01:50:49] lew at mailduct dot com wez -- the problems reported here are all due to a previously fixed bug which has crept back into PHP. It has to do with how the PHP library treats EOF under FreeBSD vs Linux. You worked on this problem previously... please take a look at the currently active Bug #32858 reported by me, as well as your prior fix in Bug #25649. Thanks Lew Payne [2005-05-30 22:11:28] mjpph at stardust dot fi I haven't had problems with different kernels. Only the combination of x86_64, stream_socket_client() or stream_socket_server(), stream_select() and PHP OpenSSL-support seem to reproduce this every time. [2005-05-30 21:57:34] fox dot 69 at gmx dot net i experience a similar problem since the latest standard kernel update with yum (host.domain.com point to the main server IP) : http://host.domain.com";; $fp = fopen ($url,"r"); $buffer=fread($fp,8192); fclose($fp); echo $buffer; ?> booted with kernel-2.6.11-1.14_FC3 package: OK booted with kernel-2.6.11-1.27_FC3 package: NOT OK (timeout) NOTE: but only if "host.domain.com" point to the executing host itself - same with "localhost" - for all others it seem to be fine 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: I haven't had problems with different kernels. Only the combination of x86_64, stream_socket_client() or stream_socket_server(), stream_select() and PHP OpenSSL-support seem to reproduce this every time. Previous Comments: [2005-05-30 21:57:34] fox dot 69 at gmx dot net i experience a similar problem since the latest standard kernel update with yum (host.domain.com point to the main server IP) : http://host.domain.com";; $fp = fopen ($url,"r"); $buffer=fread($fp,8192); fclose($fp); echo $buffer; ?> booted with kernel-2.6.11-1.14_FC3 package: OK booted with kernel-2.6.11-1.27_FC3 package: NOT OK (timeout) NOTE: but only if "host.domain.com" point to the executing host itself - same with "localhost" - for all others it seem to be fine -------- [2005-05-30 16:58:42] mjpph at stardust dot fi Also trying to compile valgrind on x86_64 results in: checking for a supported CPU... no (x86_64) configure: error: Unsupported host architecture. Sorry -------- [2005-05-30 16:56:03] mjpph at stardust dot fi I could, but I get this: valgrind: Can only handle 32-bit executables On a 32bit executable and with openssl stream_select() worked ok. On a 64bit PHP executable it doesn't. [2005-05-30 16:33:24] [EMAIL PROTECTED] Can you now check it with valgrind, please? ------------ [2005-05-30 15:53:58] mjpph at stardust dot fi Ok the latest snapshot compiled cleanly on x86_64. The stream_select() bug is still present in the latest snapshot. 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: Also trying to compile valgrind on x86_64 results in: checking for a supported CPU... no (x86_64) configure: error: Unsupported host architecture. Sorry Previous Comments: [2005-05-30 16:56:03] mjpph at stardust dot fi I could, but I get this: valgrind: Can only handle 32-bit executables On a 32bit executable and with openssl stream_select() worked ok. On a 64bit PHP executable it doesn't. [2005-05-30 16:33:24] [EMAIL PROTECTED] Can you now check it with valgrind, please? [2005-05-30 15:53:58] mjpph at stardust dot fi Ok the latest snapshot compiled cleanly on x86_64. The stream_select() bug is still present in the latest snapshot. [2005-05-30 15:37:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip (the compile error should be fixed, plus it should be more 64bit friendly :) [2005-05-28 11:56:37] mjpph at stardust dot fi Looks like this might also be a x86_64 problem. As I compiled the same exact version on i386 FC3 and got it working even with openssl compiled in. 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Fbk->Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi -Status: Feedback +Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: I could, but I get this: valgrind: Can only handle 32-bit executables On a 32bit executable and with openssl stream_select() worked ok. On a 64bit PHP executable it doesn't. Previous Comments: [2005-05-30 16:33:24] [EMAIL PROTECTED] Can you now check it with valgrind, please? [2005-05-30 15:53:58] mjpph at stardust dot fi Ok the latest snapshot compiled cleanly on x86_64. The stream_select() bug is still present in the latest snapshot. [2005-05-30 15:37:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip (the compile error should be fixed, plus it should be more 64bit friendly :) [2005-05-28 11:56:37] mjpph at stardust dot fi Looks like this might also be a x86_64 problem. As I compiled the same exact version on i386 FC3 and got it working even with openssl compiled in. [2005-05-28 11:37:29] mjpph at stardust dot fi A problem. I'm running x86_64 FC3 and PHP and valgrind seems to be able to do 32bit executables only. 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Fbk->Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi -Status: Feedback +Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: Ok the latest snapshot compiled cleanly on x86_64. The stream_select() bug is still present in the latest snapshot. Previous Comments: [2005-05-30 15:37:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip (the compile error should be fixed, plus it should be more 64bit friendly :) [2005-05-28 11:56:37] mjpph at stardust dot fi Looks like this might also be a x86_64 problem. As I compiled the same exact version on i386 FC3 and got it working even with openssl compiled in. [2005-05-28 11:37:29] mjpph at stardust dot fi A problem. I'm running x86_64 FC3 and PHP and valgrind seems to be able to do 32bit executables only. [2005-05-28 11:06:46] mjpph at stardust dot fi I guess you need valgrind --tool=callgrind. Also on another matter, I'm unable to compile the newest CVS on FC3. I get this error even without any configure options : libtool: link: `ext/libxml/libxml.lo' is not a valid libtool object. [2005-05-28 11:03:00] mjpph at stardust dot fi Sure thing, just tell me what to do. I've never even heard of valgrind before, but it seems FC3 comes with one. 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: Looks like this might also be a x86_64 problem. As I compiled the same exact version on i386 FC3 and got it working even with openssl compiled in. Previous Comments: [2005-05-28 11:37:29] mjpph at stardust dot fi A problem. I'm running x86_64 FC3 and PHP and valgrind seems to be able to do 32bit executables only. [2005-05-28 11:06:46] mjpph at stardust dot fi I guess you need valgrind --tool=callgrind. Also on another matter, I'm unable to compile the newest CVS on FC3. I get this error even without any configure options : libtool: link: `ext/libxml/libxml.lo' is not a valid libtool object. [2005-05-28 11:03:00] mjpph at stardust dot fi Sure thing, just tell me what to do. I've never even heard of valgrind before, but it seems FC3 comes with one. [2005-05-28 04:39:07] [EMAIL PROTECTED] That's the missing piece of the puzzle. openssl replaces the default tcp transport, but passes through to the default when you don't request ssl. So, the behaviour should be identical. Can you run the openssl enabled version under valgrind for me, to see if something is misbehaving? It'll give me a headstart when I sit down to solve the problem in the morning. Thanks. -------- [2005-05-27 22:05:33] mjpph at stardust dot fi It's too bad that the openssl screws up the stream_select or stream_socket_client in some weird way as I intended to use stream_socket_enable_crypto() with the stream_socket_client() and it's dependant of openssl. 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: A problem. I'm running x86_64 FC3 and PHP and valgrind seems to be able to do 32bit executables only. Previous Comments: [2005-05-28 11:06:46] mjpph at stardust dot fi I guess you need valgrind --tool=callgrind. Also on another matter, I'm unable to compile the newest CVS on FC3. I get this error even without any configure options : libtool: link: `ext/libxml/libxml.lo' is not a valid libtool object. [2005-05-28 11:03:00] mjpph at stardust dot fi Sure thing, just tell me what to do. I've never even heard of valgrind before, but it seems FC3 comes with one. [2005-05-28 04:39:07] [EMAIL PROTECTED] That's the missing piece of the puzzle. openssl replaces the default tcp transport, but passes through to the default when you don't request ssl. So, the behaviour should be identical. Can you run the openssl enabled version under valgrind for me, to see if something is misbehaving? It'll give me a headstart when I sit down to solve the problem in the morning. Thanks. -------- [2005-05-27 22:05:33] mjpph at stardust dot fi It's too bad that the openssl screws up the stream_select or stream_socket_client in some weird way as I intended to use stream_socket_enable_crypto() with the stream_socket_client() and it's dependant of openssl. ------------ [2005-05-27 21:52:35] mjpph at stardust dot fi The strangest thing.. I had time to do some test compiles with the 200505260030 snapshot and I got some working. I took my usual parameters off from configure one by one, after I removed --with-openssl the script started suddenly working. Then I did test compile with ./configure --with-openssl and without any parameters. The one --with-openssl failed the script and the one without it worked just fine. It seems that the openssl support does some havoc which causes the failures. I did proper make clean / make distclean between the compiles and doublechecked the results. Linux is a Fedora Core 3, standard install with development support enabled. The test script is as follows, the host machine has sendmail running as a test service. Strace from the working PHP (without any configure parameters): read(3, "http://bugs.php.net/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: I guess you need valgrind --tool=callgrind. Also on another matter, I'm unable to compile the newest CVS on FC3. I get this error even without any configure options : libtool: link: `ext/libxml/libxml.lo' is not a valid libtool object. Previous Comments: [2005-05-28 11:03:00] mjpph at stardust dot fi Sure thing, just tell me what to do. I've never even heard of valgrind before, but it seems FC3 comes with one. [2005-05-28 04:39:07] [EMAIL PROTECTED] That's the missing piece of the puzzle. openssl replaces the default tcp transport, but passes through to the default when you don't request ssl. So, the behaviour should be identical. Can you run the openssl enabled version under valgrind for me, to see if something is misbehaving? It'll give me a headstart when I sit down to solve the problem in the morning. Thanks. ---- [2005-05-27 22:05:33] mjpph at stardust dot fi It's too bad that the openssl screws up the stream_select or stream_socket_client in some weird way as I intended to use stream_socket_enable_crypto() with the stream_socket_client() and it's dependant of openssl. -------- [2005-05-27 21:52:35] mjpph at stardust dot fi The strangest thing.. I had time to do some test compiles with the 200505260030 snapshot and I got some working. I took my usual parameters off from configure one by one, after I removed --with-openssl the script started suddenly working. Then I did test compile with ./configure --with-openssl and without any parameters. The one --with-openssl failed the script and the one without it worked just fine. It seems that the openssl support does some havoc which causes the failures. I did proper make clean / make distclean between the compiles and doublechecked the results. Linux is a Fedora Core 3, standard install with development support enabled. The test script is as follows, the host machine has sendmail running as a test service. Strace from the working PHP (without any configure parameters): read(3, "http://bugs.php.net/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Fbk->Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi -Status: Feedback +Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: Sure thing, just tell me what to do. I've never even heard of valgrind before, but it seems FC3 comes with one. Previous Comments: [2005-05-28 04:39:07] [EMAIL PROTECTED] That's the missing piece of the puzzle. openssl replaces the default tcp transport, but passes through to the default when you don't request ssl. So, the behaviour should be identical. Can you run the openssl enabled version under valgrind for me, to see if something is misbehaving? It'll give me a headstart when I sit down to solve the problem in the morning. Thanks. [2005-05-27 22:05:33] mjpph at stardust dot fi It's too bad that the openssl screws up the stream_select or stream_socket_client in some weird way as I intended to use stream_socket_enable_crypto() with the stream_socket_client() and it's dependant of openssl. ---- [2005-05-27 21:52:35] mjpph at stardust dot fi The strangest thing.. I had time to do some test compiles with the 200505260030 snapshot and I got some working. I took my usual parameters off from configure one by one, after I removed --with-openssl the script started suddenly working. Then I did test compile with ./configure --with-openssl and without any parameters. The one --with-openssl failed the script and the one without it worked just fine. It seems that the openssl support does some havoc which causes the failures. I did proper make clean / make distclean between the compiles and doublechecked the results. Linux is a Fedora Core 3, standard install with development support enabled. The test script is as follows, the host machine has sendmail running as a test service. Strace from the working PHP (without any configure parameters): read(3, "http://bugs.php.net/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: It's too bad that the openssl screws up the stream_select or stream_socket_client in some weird way as I intended to use stream_socket_enable_crypto() with the stream_socket_client() and it's dependant of openssl. Previous Comments: [2005-05-27 21:52:35] mjpph at stardust dot fi The strangest thing.. I had time to do some test compiles with the 200505260030 snapshot and I got some working. I took my usual parameters off from configure one by one, after I removed --with-openssl the script started suddenly working. Then I did test compile with ./configure --with-openssl and without any parameters. The one --with-openssl failed the script and the one without it worked just fine. It seems that the openssl support does some havoc which causes the failures. I did proper make clean / make distclean between the compiles and doublechecked the results. Linux is a Fedora Core 3, standard install with development support enabled. The test script is as follows, the host machine has sendmail running as a test service. Strace from the working PHP (without any configure parameters): read(3, "http://bugs.php.net/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Fbk->Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi -Status: Feedback +Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: The strangest thing.. I had time to do some test compiles with the 200505260030 snapshot and I got some working. I took my usual parameters off from configure one by one, after I removed --with-openssl the script started suddenly working. Then I did test compile with ./configure --with-openssl and without any parameters. The one --with-openssl failed the script and the one without it worked just fine. It seems that the openssl support does some havoc which causes the failures. I did proper make clean / make distclean between the compiles and doublechecked the results. Linux is a Fedora Core 3, standard install with development support enabled. The test script is as follows, the host machine has sendmail running as a test service. Strace from the working PHP (without any configure parameters): read(3, "http://bugs.php.net/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Asn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Assigned Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: Also, I run constantly a lot more complex PHP-scripts on both FC2 and FC3 servers, on different kernels and by using normal socket and stream functions. They all function perfectly well. All this seems to point to the new stream_socket functions as stream_select works with all the other streams except the ones opened with stream_socket functions. Previous Comments: [2005-05-27 14:10:52] mjpph at stardust dot fi Only change has been the service port and sometimes the IP if the actual server doesn't host it's own SMTP. I've tested the SMTP availability with telnet and by using fgets instead of stream_select. So yes, the test code fails on FC3 and works on FC2 when the actual ip:port is changed to point to an available SMTP service. [2005-05-27 14:06:00] [EMAIL PROTECTED] Have you pasted the script that you're actually running with those straces? Are you really using the one from your initial post? [2005-05-27 09:59:17] mjpph at stardust dot fi Also, all the kernels I've used are different versions of FC3 stock kernels without modifications. As FC3 is quite popular Linux I'd assume that many people will have problems with the new functions when they adopt them. Of course it can be a kernel problem, but it can also be a PHP problem which only exhibits on FC3 or with certain kernel settings, but that's more your field to conclude than mine :) -------- [2005-05-26 19:18:35] mjpph at stardust dot fi Yes it works with FC2 but not with FC3, but I have tested it with several kernels the only thing that matches is Fedora Core version. Also socket_select and stream_select works perfectly well with other streams/sockets, only exceptions are streams returned by stream_socket_client() or stream_socket_server(). [2005-05-26 18:54:13] [EMAIL PROTECTED] So, PHP works fine on FC2, and the same version of PHP doesn't work on FC3? Sounds like you have a problem with your kernel; if so, this isn't a php bug. 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Asn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
Status: Assigned
Bug Type: Network related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
Assigned To: wez
New Comment:
Only change has been the service port and sometimes the IP if the
actual server doesn't host it's own SMTP. I've tested the SMTP
availability with telnet and by using fgets instead of stream_select.
So yes, the test code fails on FC3 and works on FC2 when the actual
ip:port is changed to point to an available SMTP service.
Previous Comments:
[2005-05-27 14:06:00] [EMAIL PROTECTED]
Have you pasted the script that you're actually running with those
straces?
Are you really using the one from your initial post?
[2005-05-27 09:59:17] mjpph at stardust dot fi
Also, all the kernels I've used are different versions of FC3 stock
kernels without modifications. As FC3 is quite popular Linux I'd assume
that many people will have problems with the new functions when they
adopt them. Of course it can be a kernel problem, but it can also be a
PHP problem which only exhibits on FC3 or with certain kernel settings,
but that's more your field to conclude than mine :)
--------
[2005-05-26 19:18:35] mjpph at stardust dot fi
Yes it works with FC2 but not with FC3, but I have tested it with
several kernels the only thing that matches is Fedora Core version.
Also socket_select and stream_select works perfectly well with other
streams/sockets, only exceptions are streams returned by
stream_socket_client() or stream_socket_server().
[2005-05-26 18:54:13] [EMAIL PROTECTED]
So, PHP works fine on FC2, and the same version of PHP doesn't work on
FC3?
Sounds like you have a problem with your kernel; if so, this isn't a
php bug.
------------
[2005-05-26 17:50:51] mjpph at stardust dot fi
Another update. I modified the test script to connect to HTTP which
doesn't output anything directly but instead waits for request from the
client. In this case the select timeouts on FC3 like it should, but
obviously doesn't return anything either as the connection doesn't
output anything. When the HTTP closes the connection the stream_select
starts behaving like with the SMTP example, looping as fast as it can.
If I change the port to SMTP with instant output, it loops the
stream_select() like a madman without the requested 5 second delay.
The working (FC2) script:
select(4, [3], [], [], {0, 5000}) = 0 (Timeout)
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 4000})
select(4, [3], NULL, NULL, {60, 0}) = 1 (in [3], left {60, 0})
First it selects and timeouts when waiting for data, then it returns 1
for changed streams and the stream resource (3) as the changed stream.
So this works as expected.
Here, the non-working FC3 version:
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {4, 998000})
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {5, 5000})
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {5, 5000})
It returns the same as the FC2 (except the one with the nulls) so this
should indicate AND return PHP's stream_select() with the value of 1,
but by checking the PHP's stream_select() return value it's always 0.
It's like the system level select() works ok but the PHP function fails
to return it's results correctly? Also something that bothers with me
this conclusion is that there's not a single timeout in the FC3 case
which could indicate some other problem as well, maybe the connection
isn't established correctly?
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/32979
--
Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Asn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
Status: Assigned
Bug Type: Network related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
Assigned To: wez
New Comment:
Also, all the kernels I've used are different versions of FC3 stock
kernels without modifications. As FC3 is quite popular Linux I'd assume
that many people will have problems with the new functions when they
adopt them. Of course it can be a kernel problem, but it can also be a
PHP problem which only exhibits on FC3 or with certain kernel settings,
but that's more your field to conclude than mine :)
Previous Comments:
[2005-05-26 19:18:35] mjpph at stardust dot fi
Yes it works with FC2 but not with FC3, but I have tested it with
several kernels the only thing that matches is Fedora Core version.
Also socket_select and stream_select works perfectly well with other
streams/sockets, only exceptions are streams returned by
stream_socket_client() or stream_socket_server().
[2005-05-26 18:54:13] [EMAIL PROTECTED]
So, PHP works fine on FC2, and the same version of PHP doesn't work on
FC3?
Sounds like you have a problem with your kernel; if so, this isn't a
php bug.
----
[2005-05-26 17:50:51] mjpph at stardust dot fi
Another update. I modified the test script to connect to HTTP which
doesn't output anything directly but instead waits for request from the
client. In this case the select timeouts on FC3 like it should, but
obviously doesn't return anything either as the connection doesn't
output anything. When the HTTP closes the connection the stream_select
starts behaving like with the SMTP example, looping as fast as it can.
If I change the port to SMTP with instant output, it loops the
stream_select() like a madman without the requested 5 second delay.
The working (FC2) script:
select(4, [3], [], [], {0, 5000}) = 0 (Timeout)
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 4000})
select(4, [3], NULL, NULL, {60, 0}) = 1 (in [3], left {60, 0})
First it selects and timeouts when waiting for data, then it returns 1
for changed streams and the stream resource (3) as the changed stream.
So this works as expected.
Here, the non-working FC3 version:
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {4, 998000})
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {5, 5000})
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {5, 5000})
It returns the same as the FC2 (except the one with the nulls) so this
should indicate AND return PHP's stream_select() with the value of 1,
but by checking the PHP's stream_select() return value it's always 0.
It's like the system level select() works ok but the PHP function fails
to return it's results correctly? Also something that bothers with me
this conclusion is that there's not a single timeout in the FC3 case
which could indicate some other problem as well, maybe the connection
isn't established correctly?
----------------
[2005-05-26 17:38:20] mjpph at stardust dot fi
I also noticed something funny now. If I use 5 second delay on the
stream_select and watch strace directly it doesn't wait at all, it just
loops stream_select() as fast as it can. Also there's no timeout on the
FC3 straces, but there is one timeout before the successful select on
FC2 strace. One can conclude that the SMTP server responds with 5ms+
delay causing stream_select to timeout once before it gets input. It's
like the FC3 script returns from the stream_select() for some reason
with instant timeout and not actually doing the actual select at all.
----------------
[2005-05-26 17:30:16] mjpph at stardust dot fi
Also PHP 5.1.0-dev (cli) (built: May 21 2005 21:29:39)
works fine under FC2. It seems this is PHP<>FC3 issue.
Here's strace from the working (FC2) script:
connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation now in
progress)
select(4, [3], [3], [3], {60, 0}) = 1 (out [3], left {60, 0})
getsockopt(3, SOL_SOCKET, SO_ERROR, [17179869184], [4]) = 0
fcntl(3, F_SETFL, O_RDWR) = 0
select(4, [3], [], [], {0, 5000}) = 0 (Timeout)
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 4000})
Here's strace from the non-working version (FC3)
connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}],
1, 6) =
#32979 [Fbk->Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
-Status: Feedback
+Status: Open
Bug Type: Network related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
Assigned To: wez
New Comment:
Yes it works with FC2 but not with FC3, but I have tested it with
several kernels the only thing that matches is Fedora Core version.
Also socket_select and stream_select works perfectly well with other
streams/sockets, only exceptions are streams returned by
stream_socket_client() or stream_socket_server().
Previous Comments:
[2005-05-26 18:54:13] [EMAIL PROTECTED]
So, PHP works fine on FC2, and the same version of PHP doesn't work on
FC3?
Sounds like you have a problem with your kernel; if so, this isn't a
php bug.
[2005-05-26 17:50:51] mjpph at stardust dot fi
Another update. I modified the test script to connect to HTTP which
doesn't output anything directly but instead waits for request from the
client. In this case the select timeouts on FC3 like it should, but
obviously doesn't return anything either as the connection doesn't
output anything. When the HTTP closes the connection the stream_select
starts behaving like with the SMTP example, looping as fast as it can.
If I change the port to SMTP with instant output, it loops the
stream_select() like a madman without the requested 5 second delay.
The working (FC2) script:
select(4, [3], [], [], {0, 5000}) = 0 (Timeout)
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 4000})
select(4, [3], NULL, NULL, {60, 0}) = 1 (in [3], left {60, 0})
First it selects and timeouts when waiting for data, then it returns 1
for changed streams and the stream resource (3) as the changed stream.
So this works as expected.
Here, the non-working FC3 version:
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {4, 998000})
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {5, 5000})
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {5, 5000})
It returns the same as the FC2 (except the one with the nulls) so this
should indicate AND return PHP's stream_select() with the value of 1,
but by checking the PHP's stream_select() return value it's always 0.
It's like the system level select() works ok but the PHP function fails
to return it's results correctly? Also something that bothers with me
this conclusion is that there's not a single timeout in the FC3 case
which could indicate some other problem as well, maybe the connection
isn't established correctly?
------------
[2005-05-26 17:38:20] mjpph at stardust dot fi
I also noticed something funny now. If I use 5 second delay on the
stream_select and watch strace directly it doesn't wait at all, it just
loops stream_select() as fast as it can. Also there's no timeout on the
FC3 straces, but there is one timeout before the successful select on
FC2 strace. One can conclude that the SMTP server responds with 5ms+
delay causing stream_select to timeout once before it gets input. It's
like the FC3 script returns from the stream_select() for some reason
with instant timeout and not actually doing the actual select at all.
----------------
[2005-05-26 17:30:16] mjpph at stardust dot fi
Also PHP 5.1.0-dev (cli) (built: May 21 2005 21:29:39)
works fine under FC2. It seems this is PHP<>FC3 issue.
Here's strace from the working (FC2) script:
connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation now in
progress)
select(4, [3], [3], [3], {60, 0}) = 1 (out [3], left {60, 0})
getsockopt(3, SOL_SOCKET, SO_ERROR, [17179869184], [4]) = 0
fcntl(3, F_SETFL, O_RDWR) = 0
select(4, [3], [], [], {0, 5000}) = 0 (Timeout)
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 4000})
Here's strace from the non-working version (FC3)
connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}],
1, 6) = 1
getsockopt(3, SOL_SOCKET, SO_ERROR, "\0\0\0\0", [12884901892]) = 0
fcntl(3, F_SETFL, O_RDWR) = 0
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 0})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
.. to the infinity.
[2005-05-26 16:56:43]
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
Status: Open
Bug Type: Network related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
Assigned To: wez
New Comment:
I also noticed something funny now. If I use 5 second delay on the
stream_select and watch strace directly it doesn't wait at all, it just
loops stream_select() as fast as it can. Also there's no timeout on the
FC3 straces, but there is one timeout before the successful select on
FC2 strace. One can conclude that the SMTP server responds with 5ms+
delay causing stream_select to timeout once before it gets input. It's
like the FC3 script returns from the stream_select() for some reason
with instant timeout and not actually doing the actual select at all.
Previous Comments:
[2005-05-26 17:30:16] mjpph at stardust dot fi
Also PHP 5.1.0-dev (cli) (built: May 21 2005 21:29:39)
works fine under FC2. It seems this is PHP<>FC3 issue.
Here's strace from the working (FC2) script:
connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation now in
progress)
select(4, [3], [3], [3], {60, 0}) = 1 (out [3], left {60, 0})
getsockopt(3, SOL_SOCKET, SO_ERROR, [17179869184], [4]) = 0
fcntl(3, F_SETFL, O_RDWR) = 0
select(4, [3], [], [], {0, 5000}) = 0 (Timeout)
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 4000})
Here's strace from the non-working version (FC3)
connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}],
1, 6) = 1
getsockopt(3, SOL_SOCKET, SO_ERROR, "\0\0\0\0", [12884901892]) = 0
fcntl(3, F_SETFL, O_RDWR) = 0
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 0})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
.. to the infinity.
----------------
[2005-05-26 16:56:43] mjpph at stardust dot fi
The latter has actual ip which I intended to not show, but anyway I had
to use actual IP on the other test machine as it doesn't run it's own
SMTP. Using the actual ip instead of the 127.0.0.1 didn't have any
impact on the non-working machines though.
------------
[2005-05-26 16:54:38] mjpph at stardust dot fi
New info, I was able to get the reproduce code to actually work as it's
intended on a Fedora Core 2 machine with PHP 5.0.0RC3 (cgi) (built: Jun
10 2004 16:56:32). Here's strace of it:
read(3, "http://bugs.php.net/32979
--
Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
Status: Open
Bug Type: Network related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
Assigned To: wez
New Comment:
Also PHP 5.1.0-dev (cli) (built: May 21 2005 21:29:39)
works fine under FC2. It seems this is PHP<>FC3 issue.
Here's strace from the working (FC2) script:
connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation now in
progress)
select(4, [3], [3], [3], {60, 0}) = 1 (out [3], left {60, 0})
getsockopt(3, SOL_SOCKET, SO_ERROR, [17179869184], [4]) = 0
fcntl(3, F_SETFL, O_RDWR) = 0
select(4, [3], [], [], {0, 5000}) = 0 (Timeout)
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 4000})
Here's strace from the non-working version (FC3)
connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}],
1, 6) = 1
getsockopt(3, SOL_SOCKET, SO_ERROR, "\0\0\0\0", [12884901892]) = 0
fcntl(3, F_SETFL, O_RDWR) = 0
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 0})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
.. to the infinity.
Previous Comments:
------------
[2005-05-26 16:56:43] mjpph at stardust dot fi
The latter has actual ip which I intended to not show, but anyway I had
to use actual IP on the other test machine as it doesn't run it's own
SMTP. Using the actual ip instead of the 127.0.0.1 didn't have any
impact on the non-working machines though.
----------------
[2005-05-26 16:54:38] mjpph at stardust dot fi
New info, I was able to get the reproduce code to actually work as it's
intended on a Fedora Core 2 machine with PHP 5.0.0RC3 (cgi) (built: Jun
10 2004 16:56:32). Here's strace of it:
read(3, "http://bugs.php.net/32979
--
Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
Status: Open
Bug Type: Network related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
Assigned To: wez
New Comment:
Another update. I modified the test script to connect to HTTP which
doesn't output anything directly but instead waits for request from the
client. In this case the select timeouts on FC3 like it should, but
obviously doesn't return anything either as the connection doesn't
output anything. When the HTTP closes the connection the stream_select
starts behaving like with the SMTP example, looping as fast as it can.
If I change the port to SMTP with instant output, it loops the
stream_select() like a madman without the requested 5 second delay.
The working (FC2) script:
select(4, [3], [], [], {0, 5000}) = 0 (Timeout)
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 4000})
select(4, [3], NULL, NULL, {60, 0}) = 1 (in [3], left {60, 0})
First it selects and timeouts when waiting for data, then it returns 1
for changed streams and the stream resource (3) as the changed stream.
So this works as expected.
Here, the non-working FC3 version:
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {4, 998000})
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {5, 5000})
select(4, [3], [], [], {5, 5000}) = 1 (in [3], left {5, 5000})
It returns the same as the FC2 (except the one with the nulls) so this
should indicate AND return PHP's stream_select() with the value of 1,
but by checking the PHP's stream_select() return value it's always 0.
It's like the system level select() works ok but the PHP function fails
to return it's results correctly? Also something that bothers with me
this conclusion is that there's not a single timeout in the FC3 case
which could indicate some other problem as well, maybe the connection
isn't established correctly?
Previous Comments:
----------------
[2005-05-26 17:38:20] mjpph at stardust dot fi
I also noticed something funny now. If I use 5 second delay on the
stream_select and watch strace directly it doesn't wait at all, it just
loops stream_select() as fast as it can. Also there's no timeout on the
FC3 straces, but there is one timeout before the successful select on
FC2 strace. One can conclude that the SMTP server responds with 5ms+
delay causing stream_select to timeout once before it gets input. It's
like the FC3 script returns from the stream_select() for some reason
with instant timeout and not actually doing the actual select at all.
----------------
[2005-05-26 17:30:16] mjpph at stardust dot fi
Also PHP 5.1.0-dev (cli) (built: May 21 2005 21:29:39)
works fine under FC2. It seems this is PHP<>FC3 issue.
Here's strace from the working (FC2) script:
connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation now in
progress)
select(4, [3], [3], [3], {60, 0}) = 1 (out [3], left {60, 0})
getsockopt(3, SOL_SOCKET, SO_ERROR, [17179869184], [4]) = 0
fcntl(3, F_SETFL, O_RDWR) = 0
select(4, [3], [], [], {0, 5000}) = 0 (Timeout)
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 4000})
Here's strace from the non-working version (FC3)
connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}],
1, 6) = 1
getsockopt(3, SOL_SOCKET, SO_ERROR, "\0\0\0\0", [12884901892]) = 0
fcntl(3, F_SETFL, O_RDWR) = 0
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 0})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
select(4, [3], [], [], {0, 5000}) = 1 (in [3], left {0, 5000})
.. to the infinity.
------------
[2005-05-26 16:56:43] mjpph at stardust dot fi
The latter has actual ip which I intended to not show, but anyway I had
to use actual IP on the other test machine as it doesn't run it's own
SMTP. Using the actual ip instead of the 127.0.0.1 didn't have any
impact on the non-working machines though.
[2005-05-26 16:54:38] mjpph at stardust dot fi
New info, I was able to get the reproduce code to actually work as it's
intended on a Fedora Core 2 machine with PHP 5.0.0RC3 (cgi) (built: Jun
10 2004 16:56:32). Here's strace of it:
read(3, "http://bugs.php.net/32979
--
Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: The latter has actual ip which I intended to not show, but anyway I had to use actual IP on the other test machine as it doesn't run it's own SMTP. Using the actual ip instead of the 127.0.0.1 didn't have any impact on the non-working machines though. Previous Comments: [2005-05-26 16:54:38] mjpph at stardust dot fi New info, I was able to get the reproduce code to actually work as it's intended on a Fedora Core 2 machine with PHP 5.0.0RC3 (cgi) (built: Jun 10 2004 16:56:32). Here's strace of it: read(3, "http://bugs.php.net/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: New info, I was able to get the reproduce code to actually work as it's intended on a Fedora Core 2 machine with PHP 5.0.0RC3 (cgi) (built: Jun 10 2004 16:56:32). Here's strace of it: read(3, "http://bugs.php.net/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Fbk->Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi -Status: Feedback +Status: Open Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: I used the reproduce code to connect to my own SMTP server, which by using standard socket functions, telnet or any other method instantly outputs the welcome message when I connect. Just add IP+Port to some SMTP server and it'll work for the test. Here's the strace: read(3, "http://bugs.php.net/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32838 [Fbk->Opn]: child processes opened with proc_open freeze the script
ID: 32838 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi -Status: Feedback +Status: Open Bug Type: Program Execution Operating System: Linux PHP Version: 5.0.4 New Comment: It seems the snapshot sniper posted has solved the bug. I usually was able to freeze atleast one script in say 48 hours with almost 100% propability. Usually more than one script. This time around, with the sniper's snapshot, the scripts have been running for over 120 hours without a single failure. I think it's safe to say this bug has been solved. Thanks a lot, I wrestled with this bug for a long time. Previous Comments: [2005-05-11 10:02:21] [EMAIL PROTECTED] Are you still able to reproduce it? [2005-05-08 16:34:06] mjpph at stardust dot fi It looks like the newest snapshot has fixed the issue. I've been now running the scripts for 55 hours without one single failure. Before this atleast one, most likely half of the scripts would have freezed already. I'll send some more feedback after few more days of testing. [2005-05-06 09:07:54] mjpph at stardust dot fi Ok I'll try that snapshot. One thing I notice too, all version seem to have PTY support of the proc_open disabled. It can be easily seen by checking ext/standard/proc_open.c which has two pty-related defines which start by "0 &&". I changed these and got fully working proc_open PTY support on my system. This didn't have any effect on the freezing problem though. Maybe the PTY support is still buggy or someone has tested something and forgot to enable it? Just as a sidenote. [2005-05-06 03:21:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip ------------ [2005-05-05 15:16:41] mjpph at stardust dot fi More info. I have a identical script running on a machine with PHP 5.0.0RC3, it has no problems mentioned here. All scripts run perfectly well. When I run the identical script on 5.0.4 it freezes after some time of runtime almost without exceptions. Both are CLI versions compiled from the source. The hltv-runner started to freeze after I upgraded PHP from 5.0.0RC3 to 5.0.4, it never did before the upgrade. 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/32838 -- Edit this bug report at http://bugs.php.net/?id=32838&edit=1
#32979 [Fbk->Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
New Comment:
No I used http only as an examply not thinking that it doesn't actually
output anything straight away.
I used the example code on several services that output information
straight from connect without needing any input from the client. For
example port 25 welcome message and several others. Telnet straight
away you get a welcome. Use only fgets, you get a welcome. Use the
example code, you get nothing. Didn't try anything which actually
closes the connection after the output, as this isn't the case with my
own implementation either and shouldn't be a requirement anyway.
The case is always the same, fgets would get input straight away but
stream_select stays dead no matter how many times it loops and waits.
Setting the stream to blocking or non-blocking mode has no effect on
stream_select's behaviour on this case. The data in the buffer just
stays there and stream_select is completely ignorant about it. So, the
read wouldn't block (as I know there is data pending), but even despite
that stream_select returns 0 changed streams always. So it thinks that
read would block, in reality, it doesn't.
Partly unrelated: I have this code in a script which also selects
stdin. The stdin select works as expected, the stream_socket selecting
select doesn't. I had a perfectly working implementation with
socket-based functions which stalled at the selects right after I
changed to stream_socket-based functions.
Previous Comments:
[2005-05-09 01:26:32] [EMAIL PROTECTED]
Is the server end of the socket talking http?
If not, does it send data to the client immediately upon client
connection (without expecting data from the client first)?
If not, stream_select() is working precisely as it should.
Also note that stream_select() tells you only if a read or write would
not block, not whether there actually is data pending.
--------
[2005-05-08 23:06:40] mjpph at stardust dot fi
The issue is the same when using stream_socket_server.
stream_socket_accept works as expected, but if you select the socket it
always returns 0, even if there is a pending connection which would be
returned with stream_socket_accept.
--------
[2005-05-08 22:50:58] mjpph at stardust dot fi
Correction to the previous comment. The fread has to be done before
every stream_select to obtain any other value from stream_select other
than 0. stream_get_meta_data also reports pending data as 0 before the
fread and non-zero value right after the 1 byte fread.
--------
[2005-05-08 22:46:55] mjpph at stardust dot fi
Also, adding "fread($c,1);" after stream_socket_client and before the
while loop enables correct functionality of the stream_select function
from that pont on.
----------------
[2005-05-08 22:18:29] mjpph at stardust dot fi
Description:
Using stream_socket_client or stream_socket_server to open a connection
fails to report correct values with stream_select. Using fread to get
one byte before stream_select suddenly makes stream_select work as
expected.
Without it stream_select returns 0 changed streams even though there is
data waiting. Service used as an endpoint is persistent and doesn't
close the connection after it's output. PHP is CLI-version.
Reproduce code:
---
$c = stream_socket_client("tcp://127.0.0.1:80");
while (1)
{
$streams = array($c);
if (stream_select($streams, $write=NULL, $except=NULL, 0, 5000)) {
print "Data received\n";
}
}
// IP:Port can be anything which outputs something after connection.
Expected result:
Text "Data received" after connection and output from the service. The
service can be anything which just outputs something right after
connect.
Actual result:
--
Nothing. stream_select returns 0 even though there is data waiting.
--
Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
Status: Open
Bug Type: CGI related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
New Comment:
The issue is the same when using stream_socket_server.
stream_socket_accept works as expected, but if you select the socket it
always returns 0, even if there is a pending connection which would be
returned with stream_socket_accept.
Previous Comments:
[2005-05-08 22:50:58] mjpph at stardust dot fi
Correction to the previous comment. The fread has to be done before
every stream_select to obtain any other value from stream_select other
than 0. stream_get_meta_data also reports pending data as 0 before the
fread and non-zero value right after the 1 byte fread.
[2005-05-08 22:46:55] mjpph at stardust dot fi
Also, adding "fread($c,1);" after stream_socket_client and before the
while loop enables correct functionality of the stream_select function
from that pont on.
[2005-05-08 22:18:29] mjpph at stardust dot fi
Description:
Using stream_socket_client or stream_socket_server to open a connection
fails to report correct values with stream_select. Using fread to get
one byte before stream_select suddenly makes stream_select work as
expected.
Without it stream_select returns 0 changed streams even though there is
data waiting. Service used as an endpoint is persistent and doesn't
close the connection after it's output. PHP is CLI-version.
Reproduce code:
---
$c = stream_socket_client("tcp://127.0.0.1:80");
while (1)
{
$streams = array($c);
if (stream_select($streams, $write=NULL, $except=NULL, 0, 5000)) {
print "Data received\n";
}
}
// IP:Port can be anything which outputs something after connection.
Expected result:
Text "Data received" after connection and output from the service. The
service can be anything which just outputs something right after
connect.
Actual result:
--
Nothing. stream_select returns 0 even though there is data waiting.
--
Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
Status: Open
Bug Type: CGI related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
New Comment:
Correction to the previous comment. The fread has to be done before
every stream_select to obtain any other value from stream_select other
than 0. stream_get_meta_data also reports pending data as 0 before the
fread and non-zero value right after the 1 byte fread.
Previous Comments:
[2005-05-08 22:46:55] mjpph at stardust dot fi
Also, adding "fread($c,1);" after stream_socket_client and before the
while loop enables correct functionality of the stream_select function
from that pont on.
[2005-05-08 22:18:29] mjpph at stardust dot fi
Description:
Using stream_socket_client or stream_socket_server to open a connection
fails to report correct values with stream_select. Using fread to get
one byte before stream_select suddenly makes stream_select work as
expected.
Without it stream_select returns 0 changed streams even though there is
data waiting. Service used as an endpoint is persistent and doesn't
close the connection after it's output. PHP is CLI-version.
Reproduce code:
---
$c = stream_socket_client("tcp://127.0.0.1:80");
while (1)
{
$streams = array($c);
if (stream_select($streams, $write=NULL, $except=NULL, 0, 5000)) {
print "Data received\n";
}
}
// IP:Port can be anything which outputs something after connection.
Expected result:
Text "Data received" after connection and output from the service. The
service can be anything which just outputs something right after
connect.
Actual result:
--
Nothing. stream_select returns 0 even though there is data waiting.
--
Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
Status: Open
Bug Type: CGI related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
New Comment:
Also, adding "fread($c,1);" after stream_socket_client and before the
while loop enables correct functionality of the stream_select function
from that pont on.
Previous Comments:
[2005-05-08 22:18:29] mjpph at stardust dot fi
Description:
Using stream_socket_client or stream_socket_server to open a connection
fails to report correct values with stream_select. Using fread to get
one byte before stream_select suddenly makes stream_select work as
expected.
Without it stream_select returns 0 changed streams even though there is
data waiting. Service used as an endpoint is persistent and doesn't
close the connection after it's output. PHP is CLI-version.
Reproduce code:
---
$c = stream_socket_client("tcp://127.0.0.1:80");
while (1)
{
$streams = array($c);
if (stream_select($streams, $write=NULL, $except=NULL, 0, 5000)) {
print "Data received\n";
}
}
// IP:Port can be anything which outputs something after connection.
Expected result:
Text "Data received" after connection and output from the service. The
service can be anything which just outputs something right after
connect.
Actual result:
--
Nothing. stream_select returns 0 even though there is data waiting.
--
Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32979 [NEW]: socket stream opened with stream_socket_client doesnt work with stream_select
From: mjpph at stardust dot fi
Operating system: Linux (Fedora Core 3)
PHP version: 5CVS-2005-05-08 (dev)
PHP Bug Type: CGI related
Bug description: socket stream opened with stream_socket_client doesnt work
with stream_select
Description:
Using stream_socket_client or stream_socket_server to open a connection
fails to report correct values with stream_select. Using fread to get one
byte before stream_select suddenly makes stream_select work as expected.
Without it stream_select returns 0 changed streams even though there is
data waiting. Service used as an endpoint is persistent and doesn't close
the connection after it's output. PHP is CLI-version.
Reproduce code:
---
$c = stream_socket_client("tcp://127.0.0.1:80");
while (1)
{
$streams = array($c);
if (stream_select($streams, $write=NULL, $except=NULL, 0, 5000)) {
print "Data received\n";
}
}
// IP:Port can be anything which outputs something after connection.
Expected result:
Text "Data received" after connection and output from the service. The
service can be anything which just outputs something right after connect.
Actual result:
--
Nothing. stream_select returns 0 even though there is data waiting.
--
Edit bug report at http://bugs.php.net/?id=32979&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32979&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32979&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32979&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32979&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32979&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32979&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32979&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32979&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32979&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32979&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32979&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32979&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32979&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32979&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32979&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32979&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32979&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32979&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32979&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32979&r=mysqlcfg
#32838 [Opn]: child processes opened with proc_open freeze the script
ID: 32838 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Program Execution Operating System: Linux PHP Version: 5.0.4 New Comment: It looks like the newest snapshot has fixed the issue. I've been now running the scripts for 55 hours without one single failure. Before this atleast one, most likely half of the scripts would have freezed already. I'll send some more feedback after few more days of testing. Previous Comments: [2005-05-06 09:07:54] mjpph at stardust dot fi Ok I'll try that snapshot. One thing I notice too, all version seem to have PTY support of the proc_open disabled. It can be easily seen by checking ext/standard/proc_open.c which has two pty-related defines which start by "0 &&". I changed these and got fully working proc_open PTY support on my system. This didn't have any effect on the freezing problem though. Maybe the PTY support is still buggy or someone has tested something and forgot to enable it? Just as a sidenote. [2005-05-06 03:21:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip -------- [2005-05-05 15:16:41] mjpph at stardust dot fi More info. I have a identical script running on a machine with PHP 5.0.0RC3, it has no problems mentioned here. All scripts run perfectly well. When I run the identical script on 5.0.4 it freezes after some time of runtime almost without exceptions. Both are CLI versions compiled from the source. The hltv-runner started to freeze after I upgraded PHP from 5.0.0RC3 to 5.0.4, it never did before the upgrade. -------- [2005-05-02 18:10:33] mjpph at stardust dot fi I'm using PHP's CLI version. Also I noticed that when I upgraded an earlier 5.x PHP to 5.0.4 it started to freeze one process runner which has always worked perfectly. The script was unchanged. Test code can be anything that just simply opens a child process which has atleast relatively high output and keeps listening to it for a long time (several hours, days). I'll add two simple test scripts asap. [2005-04-28 00:10:25] [EMAIL PROTECTED] Also specify which SAPI you are using: eg: Apache, CLI, CGI. Note that launching a CGI child process from either Apache or an existing CGI process is going to bite you unless you clean up the environmental variables you pass on to the child process. 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/32838 -- Edit this bug report at http://bugs.php.net/?id=32838&edit=1
#32838 [Fbk->Opn]: child processes opened with proc_open freeze the script
ID: 32838 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi -Status: Feedback +Status: Open Bug Type: Program Execution Operating System: Linux PHP Version: 5.0.4 New Comment: Ok I'll try that snapshot. One thing I notice too, all version seem to have PTY support of the proc_open disabled. It can be easily seen by checking ext/standard/proc_open.c which has two pty-related defines which start by "0 &&". I changed these and got fully working proc_open PTY support on my system. This didn't have any effect on the freezing problem though. Maybe the PTY support is still buggy or someone has tested something and forgot to enable it? Just as a sidenote. Previous Comments: [2005-05-06 03:21:59] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-05-05 15:16:41] mjpph at stardust dot fi More info. I have a identical script running on a machine with PHP 5.0.0RC3, it has no problems mentioned here. All scripts run perfectly well. When I run the identical script on 5.0.4 it freezes after some time of runtime almost without exceptions. Both are CLI versions compiled from the source. The hltv-runner started to freeze after I upgraded PHP from 5.0.0RC3 to 5.0.4, it never did before the upgrade. [2005-05-02 18:10:33] mjpph at stardust dot fi I'm using PHP's CLI version. Also I noticed that when I upgraded an earlier 5.x PHP to 5.0.4 it started to freeze one process runner which has always worked perfectly. The script was unchanged. Test code can be anything that just simply opens a child process which has atleast relatively high output and keeps listening to it for a long time (several hours, days). I'll add two simple test scripts asap. [2005-04-28 00:10:25] [EMAIL PROTECTED] Also specify which SAPI you are using: eg: Apache, CLI, CGI. Note that launching a CGI child process from either Apache or an existing CGI process is going to bite you unless you clean up the environmental variables you pass on to the child process. [2005-04-27 12:42:22] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. 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/32838 -- Edit this bug report at http://bugs.php.net/?id=32838&edit=1
#32838 [Opn]: child processes opened with proc_open freeze the script
ID: 32838 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Program Execution Operating System: Linux PHP Version: 5.0.4 New Comment: More info. I have a identical script running on a machine with PHP 5.0.0RC3, it has no problems mentioned here. All scripts run perfectly well. When I run the identical script on 5.0.4 it freezes after some time of runtime almost without exceptions. Both are CLI versions compiled from the source. The hltv-runner started to freeze after I upgraded PHP from 5.0.0RC3 to 5.0.4, it never did before the upgrade. Previous Comments: [2005-05-02 18:10:33] mjpph at stardust dot fi I'm using PHP's CLI version. Also I noticed that when I upgraded an earlier 5.x PHP to 5.0.4 it started to freeze one process runner which has always worked perfectly. The script was unchanged. Test code can be anything that just simply opens a child process which has atleast relatively high output and keeps listening to it for a long time (several hours, days). I'll add two simple test scripts asap. [2005-04-28 00:10:25] [EMAIL PROTECTED] Also specify which SAPI you are using: eg: Apache, CLI, CGI. Note that launching a CGI child process from either Apache or an existing CGI process is going to bite you unless you clean up the environmental variables you pass on to the child process. [2005-04-27 12:42:22] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-04-26 15:21:02] mjpph at stardust dot fi It also seems that by using only on fgets() per select to get the child process's output seems to make the script a lot more stable than for example getting the whole buffer with stream_get_contents or by loopin fgets/stream_get_line. This was also the case with the earlier script though it didn't make the script still completely stable. ---- [2005-04-26 14:31:21] mjpph at stardust dot fi Description: I've created three scripts during some time, which of the latest is under PHP 5.0.4. It opens hlds or srcds process as a child process using proc_open. Every pipe is made non-blocking also there are no infinite loops except the one that selects the child process's stdout pipe. The script reads and runs succesfully for some time, then it suddenly freezes. All buffering is turned off that can be turned off, I also added some DEBUG printouts in the code and it even once freezed in the middle of a single print. The same thing happens with pty and pipe support. Everything has been checked out dozens of times. Both the child process's stdout and stderr pipes are selected and read constantly. If the child process is terminated from a shell with a kill command the php script suddenly exits without any error or warning message even though it should keep looping the child process, which it normally does if it doesn't freeze. This behaviour is only happening with hlds and srcds child processes. I've run thousands of execution times of hltv's witht the same script and it has never freezed. Srcds and hlds processes output a lot more data though. The child process actually continues to run without any problems even if the proc_open is done without pipes and the script has frozen. Obviously the php script as a control script becomes completely useless after this. -- Edit this bug report at http://bugs.php.net/?id=32838&edit=1
#32838 [Fbk->Opn]: child processes opened with proc_open freeze the script
ID: 32838 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi -Status: Feedback +Status: Open Bug Type: Program Execution Operating System: Linux PHP Version: 5.0.4 New Comment: I'm using PHP's CLI version. Also I noticed that when I upgraded an earlier 5.x PHP to 5.0.4 it started to freeze one process runner which has always worked perfectly. The script was unchanged. Test code can be anything that just simply opens a child process which has atleast relatively high output and keeps listening to it for a long time (several hours, days). I'll add two simple test scripts asap. Previous Comments: [2005-04-28 00:10:25] [EMAIL PROTECTED] Also specify which SAPI you are using: eg: Apache, CLI, CGI. Note that launching a CGI child process from either Apache or an existing CGI process is going to bite you unless you clean up the environmental variables you pass on to the child process. [2005-04-27 12:42:22] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-04-26 15:21:02] mjpph at stardust dot fi It also seems that by using only on fgets() per select to get the child process's output seems to make the script a lot more stable than for example getting the whole buffer with stream_get_contents or by loopin fgets/stream_get_line. This was also the case with the earlier script though it didn't make the script still completely stable. ---- [2005-04-26 14:31:21] mjpph at stardust dot fi Description: I've created three scripts during some time, which of the latest is under PHP 5.0.4. It opens hlds or srcds process as a child process using proc_open. Every pipe is made non-blocking also there are no infinite loops except the one that selects the child process's stdout pipe. The script reads and runs succesfully for some time, then it suddenly freezes. All buffering is turned off that can be turned off, I also added some DEBUG printouts in the code and it even once freezed in the middle of a single print. The same thing happens with pty and pipe support. Everything has been checked out dozens of times. Both the child process's stdout and stderr pipes are selected and read constantly. If the child process is terminated from a shell with a kill command the php script suddenly exits without any error or warning message even though it should keep looping the child process, which it normally does if it doesn't freeze. This behaviour is only happening with hlds and srcds child processes. I've run thousands of execution times of hltv's witht the same script and it has never freezed. Srcds and hlds processes output a lot more data though. The child process actually continues to run without any problems even if the proc_open is done without pipes and the script has frozen. Obviously the php script as a control script becomes completely useless after this. -- Edit this bug report at http://bugs.php.net/?id=32838&edit=1
#32838 [Opn]: child processes opened with proc_open freeze the script
ID: 32838 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Program Execution Operating System: Linux PHP Version: 5.0.4 New Comment: It also seems that by using only on fgets() per select to get the child process's output seems to make the script a lot more stable than for example getting the whole buffer with stream_get_contents or by loopin fgets/stream_get_line. This was also the case with the earlier script though it didn't make the script still completely stable. Previous Comments: [2005-04-26 14:31:21] mjpph at stardust dot fi Description: I've created three scripts during some time, which of the latest is under PHP 5.0.4. It opens hlds or srcds process as a child process using proc_open. Every pipe is made non-blocking also there are no infinite loops except the one that selects the child process's stdout pipe. The script reads and runs succesfully for some time, then it suddenly freezes. All buffering is turned off that can be turned off, I also added some DEBUG printouts in the code and it even once freezed in the middle of a single print. The same thing happens with pty and pipe support. Everything has been checked out dozens of times. Both the child process's stdout and stderr pipes are selected and read constantly. If the child process is terminated from a shell with a kill command the php script suddenly exits without any error or warning message even though it should keep looping the child process, which it normally does if it doesn't freeze. This behaviour is only happening with hlds and srcds child processes. I've run thousands of execution times of hltv's witht the same script and it has never freezed. Srcds and hlds processes output a lot more data though. The child process actually continues to run without any problems even if the proc_open is done without pipes and the script has frozen. Obviously the php script as a control script becomes completely useless after this. -- Edit this bug report at http://bugs.php.net/?id=32838&edit=1
#32838 [NEW]: child processes opened with proc_open freeze the script
From: mjpph at stardust dot fi Operating system: Linux PHP version: 5.0.4 PHP Bug Type: Program Execution Bug description: child processes opened with proc_open freeze the script Description: I've created three scripts during some time, which of the latest is under PHP 5.0.4. It opens hlds or srcds process as a child process using proc_open. Every pipe is made non-blocking also there are no infinite loops except the one that selects the child process's stdout pipe. The script reads and runs succesfully for some time, then it suddenly freezes. All buffering is turned off that can be turned off, I also added some DEBUG printouts in the code and it even once freezed in the middle of a single print. The same thing happens with pty and pipe support. Everything has been checked out dozens of times. Both the child process's stdout and stderr pipes are selected and read constantly. If the child process is terminated from a shell with a kill command the php script suddenly exits without any error or warning message even though it should keep looping the child process, which it normally does if it doesn't freeze. This behaviour is only happening with hlds and srcds child processes. I've run thousands of execution times of hltv's witht the same script and it has never freezed. Srcds and hlds processes output a lot more data though. The child process actually continues to run without any problems even if the proc_open is done without pipes and the script has frozen. Obviously the php script as a control script becomes completely useless after this. -- Edit bug report at http://bugs.php.net/?id=32838&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32838&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32838&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32838&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32838&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32838&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32838&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32838&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32838&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32838&r=support Expected behavior: http://bugs.php.net/fix.php?id=32838&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32838&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32838&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32838&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32838&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32838&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32838&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32838&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32838&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32838&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32838&r=mysqlcfg
