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.

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.

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.

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.

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.

Worked for me just the other week.
You'll need to convince me with a short self-contained test and strace output to prove it.

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, "<?\n$c = stream_socket_client(\"tc"..., 8192) = 220
read(3, "", 4096)                       = 0
read(3, "", 8192)                       = 0
close(3)                                = 0
munmap(0x2aaaad2e0000, 4096)            = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
close(3)                                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}], 1, 60000) = 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, 1000})
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})
select(4, [3], [], [], {0, 5000})       = 1 (in [3], left {0, 5000})

.. it continues like this until I kill the script. The stream_select() never returns anything. If I do fgets() instead of the stream_select() it returns the SMTP welcome instantly.

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, "<?\n$c = stream_socket_client(\"tc"..., 8192) = 199
read(3, "", 4096)                       = 0
read(3, "", 8192)                       = 0
close(3)                                = 0
munmap(0x2a97e16000, 4096)              = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
close(3)                                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("83.145.20
0.2")}, 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, 5000})
select(4, [3], NULL, NULL, {60, 0})     = 1 (in [3], left {60, 0})

at this point the stream_select returns as intended and script ends.

The reproduce code DOESN'T work with several machines running Fedora Core 3 by using 5.0.4 as well as with 200505260030 dated snapshot. stream_select simply doesn't give me anything. Platform is Fedora Core 3 x86_64 under dual xeon 3.2ghz (Nocona, EM64T) with kernel 2.6.11-1.14_FC3smp on the machines that don't return stream_select() as it should.

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.

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("<HIDDEN>")}, 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("<HIDDEN>")}, 16) = -1 EINPROGRESS (Operation
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}], 1, 60000) = 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.

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.

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?

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.

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().

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 :)

Have you pasted the script that you're actually running with those straces?
Are you really using the one from your initial post?

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.

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.

Whenever I see FC3-specific problems I always suspect SELinux.  Although I don't see how that can affect a select()

*please* paste the exact script you are using that produced those straces.

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.

<?
$c = stream_socket_client("tcp://127.0.0.1:25");
while (1)
{
  $streams = array($c);
  if (stream_select($streams, $write=NULL, $except=NULL, 5, 0)) die("Select OK\n");
}
?>

Strace from the working PHP (without any configure parameters):

read(3, "<?\n$c = stream_socket_client(\"tc"..., 8192) = 221
read(3, "", 4096)                       = 0
read(3, "", 8192)                       = 0
close(3)                                = 0
munmap(0x2a97b2c000, 4096)              = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
close(3)                                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}], 1, 60000) = 1
getsockopt(3, SOL_SOCKET, SO_ERROR, "\0\0\0\0", [12884901892]) = 0
fcntl(3, F_SETFL, O_RDWR)               = 0
select(4, [3], [], [], {5, 0})          = 1 (in [3], left {4, 998000})
write(1, "Select OK\n", 10)             = 10
close(3)                                = 0
close(1)                                = 0
close(0)                                = 0

...

Strace from the non-working PHP (only --with-openssl added for configure):

read(3, "<?\n$c = stream_socket_client(\"tc"..., 8192) = 221
read(3, "", 4096)                       = 0
read(3, "", 8192)                       = 0
close(3)                                = 0
munmap(0x2a97b2f000, 4096)              = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
close(3)                                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}], 1, 60000) = 1
getsockopt(3, SOL_SOCKET, SO_ERROR, "\0\0\0\0", [12884901892]) = 0
fcntl(3, F_SETFL, O_RDWR)               = 0
select(4, [3], [], [], {5, 0})          = 1 (in [3], left {4, 998000})
select(4, [3], [], [], {5, 0})          = 1 (in [3], left {5, 0})
select(4, [3], [], [], {5, 0})          = 1 (in [3], left {5, 0})

.. continues until the script is killed

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.

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.

Sure thing, just tell me what to do. I've never even heard of valgrind before, but it seems FC3 comes with one.

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.

A problem. I'm running x86_64 FC3 and PHP and valgrind seems to be able to do 32bit executables only.

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.

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 :)

Ok the latest snapshot compiled cleanly on x86_64. The stream_select() bug is still present in the latest snapshot.

Can you now check it with valgrind, please?

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.

Also trying to compile valgrind on x86_64 results in:
checking for a supported CPU... no (x86_64)
configure: error: Unsupported host architecture. Sorry

i experience a similar problem since the latest standard kernel update with yum (host.domain.com point to the main server IP) :

<?
$url="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

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.

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

I've done some testing, and this bug is definitely triggered by 64 bit+ SSL support.

Bug triggers:
FC4 64 bit + PHP5.1.2 (configure --with-openssl)
FC4 64 bit + PHP 5.1Jan 29 snapshot (configure --with-openssl)

Bug does not trigger:
FC4 64 bit + PHP 5.1.2 (configure)
FC4 64 bit + PHP 5.1Jan29 snapshot (configure)
FC4 32 bit + PHP 5.1.2 (configure --with-openssl)
FC4 32 bit + PHP 5.0.4-10.5 (stock FC RPM)

I have compared the original socket operations code, and the one in the xp_ssl.x file, and it seems that even in the non-ssl path the code is not identical. 

I have fixed four differences, two of which caused some functions to be called twice, and two of which are casting to *(int*)

I do not claim to know the real cause for the bug, and how these changes fix the problem, but they do, and they make the code more consistent, and faster, so I think they should be committed.

Here is the patch that solves this problem form me (against 5.1.2)

------------------------cut here-----------------------
*** php-5.1.2/ext/openssl/xp_ssl.c	2006-01-01 13:50:10.000000000 +0100
--- php-5.1.2ssl/ext/openssl/xp_ssl.c	2006-01-31 23:00:58.000000000 +0100
***************
*** 188,194 ****
  		} while(retry);
  		
  	} else {
! 		didwrite = php_stream_socket_ops.write(stream, buf, count TSRMLS_CC);
  	}
  	
  	if (didwrite > 0) {
--- 188,195 ----
  		} while(retry);
  		
  	} else {
! 		didwrite = php_stream_socket_ops.write(stream, buf, count TSRMLS_CC);	
! 		return didwrite;
  	}
  	
  	if (didwrite > 0) {
***************
*** 226,231 ****
--- 227,233 ----
  	else
  	{
  		nr_bytes = php_stream_socket_ops.read(stream, buf, count TSRMLS_CC);
+ 		return nr_bytes;
  	}
  
  	if (nr_bytes > 0) {
***************
*** 636,642 ****
  
  		case PHP_STREAM_AS_FD_FOR_SELECT:
  			if (ret) {
! 				*ret = (void*)sslsock->s.socket;
  			}
  			return SUCCESS;
  
--- 638,644 ----
  
  		case PHP_STREAM_AS_FD_FOR_SELECT:
  			if (ret) {
! 				*(int*)ret = (void*)sslsock->s.socket;
  			}
  			return SUCCESS;
  
***************
*** 646,652 ****
  				return FAILURE;
  			}
  			if (ret) {
! 				*ret = (void*)sslsock->s.socket;
  			}
  			return SUCCESS;
  		default:
--- 648,654 ----
  				return FAILURE;
  			}
  			if (ret) {
! 				*(int*)ret = (void*)sslsock->s.socket;
  			}
  			return SUCCESS;
  		default:

------------------------cut here-----------------------

Bug is still present in 5.1.4

i'm having the same problem with xeon quad core (prolian HP) on linux
socket_select work ok
but stream_select don't work
i will recompile php without openssl and check what happen

the problem occur with php 5.2.4

without openssl everythink work ok now, socket and stream
where could i send .php files to develop team check it?

Joe Orton has analyzed the bug and found the root cause, see here:

http://marc.info/?l=php-internals&m=120522857529781&w=2

This bug has been fixed in CVS.

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.

This is fixed in CVS, xp_ssl.c revision 1.36, thanks to stotty@ for the patch.

I've backported it to 5.3.x; will backport to 5.2.x if it's OK with the RM too.