Tested on Linux/Intel 64, Linux/AMD 64, Linux/PPC 64 & Solaris/SPARC 64. In all cases I get:
Selected: 2
Read: Array
(
    [0] => Resource id #5
)
Write: Array
(
    [0] => Resource id #5
)

What information can I provide to help determine the cause of this 
problem on my system? Thanks!

An SSH account would be helpful.

Allowing ssh access to my machine will require me to request a 
firewall change which may take some time. However, I have found this 
behavior only presents itself when PHP is compiled with 
the --with-curlwrappers option.  Explicitly disabling this option 
returns my machine to the expected behavior.  Cheers!

I still get the expected result even with --with-curlwrappers.

After further testing it seems that --with-curlwrappers is not the 
culprit but gcc optimization is.  Using gcc version 4.1.1 (Gentoo 
4.1.1-r3) I get the expected behavior when compiling with 
CFLAGS="-pipe" but the erroneous behavior when compiling with 
CFLAGS="-pipe -O2".  This is regardless of the curlwrappers setting.  
Sorry about the initial misinformation.  Forgetting a make clean 
between several of my tests led me to the wrong conclusion.  Just 
tried -O1 and it seems to be ok, will try with a different version 
of gcc.

Try with GCC 4.1.2.
GCC 4.1.1 is known to have some problems.

Same behavior with gcc 4.1.2.  I'm chalking this up to gcc 
optimization and will compile with -O1 for now.

I still have no idea how to replicate it.

The following script reproduces the behavior (for me):

http://11434.com/stream_select.sh


Changing -O2 to -O1 or removing --with-openssl fixes the problem.

gcc version 4.1.2
openssl version 0.9.8d

Still works perfectly fine with or without OpenSSL, with and without -O2.
I think I'll need an acccount on your machine to reproduce it.

I have a x86(-32) gentoo box with the same gcc version as you and your script works perfectly. anyway if this is a compiler error, you need report it to gentoo guys, that will then investigate to see if it is caused by their patchset or not.

It is even worse on the current Debian Sid, with 5.2.3-1+b1. It returns 0 and the modified arrays contain just nothing, but there is obviosly data available there. Tested with slightly adapted code from  http://netevil.org/blog/2005/may/guru-multiplexing .

Just verified that I still see the same behavior with:
php-5.2.3
openssl-0.9.8e
gcc-4.1.2

I am using the same test script as before.  

Changing it to use:

-O1 --with-openssl
     *or*
-O2 --without-openssl
 
gives the correct behavior.

Nobody else is able to reproduce this on several different (or same) types of systems -> bogus. (reopen if you can reproduce this on 2 different machines using Fedorda..I can't. :)

I'm also seeing this problem... the code from rodricg produces the same (incorrect) result, returning Selected: 0. I was testing my own application which is how I found the bug, but rodricg's test script provides the same result. I do not have my original script, however I had a working version and when I moved everything to a class the incorrect return value became a problem, leading me to believe this is a PHP bug.

This is also an x86_64 machine with openssl and curl.

$ php -v
PHP 5.2.3 (cli) (built: Oct 29 2007 00:07:41) 
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

PHP configure:
./configure --with-apxs2=/usr/local/apache/bin/apxs --with-config-file-path=/etc --with-bz2 --enable-calendar --with-curl --with-curlwrappers --with-inifile --enable-exif --enable-ftp --with-gd --enable-json --with-mysql --with-mysqli --with-pdo-mysql --with-mssql --enable-soap --enable-sockets --with-pear --with-xsl --with-zlib --with-openssl --enable-pcntl

Send me an email, I will provide a test account as needed to those with a @php.net email. Recompiling with -O1 did NOT solve the problem for me.

This was sent to me via email so I'm posting it here in the interest 
of collecting all relevant information. 

> I have the same weird behaviour on x86_64 but with gcc-3.4.6-8 
(CentOS 4.5)
> and PHP 5.2.4
>
> P.S. I havent tested yet if it's related but I have FD_SETSIZE 
macro in
> /usr/include/* set to 16384 (instead of original 1024). Though
> stream_select in php4 has no problems.
>
> Well, I started to debug the code and noticed that system's 
select()
> returns correct return value but this value will be later 
overwritten?? and
> PHP script gets always wrong result.
>
> The cure for me was to replace an variable type from 'int' 
to 'long' in
> function stream_array_from_fd_set:
>
> --- streamsfuncs.c.orig 2007-10-09 16:21:30.000000000 +0300
> +++ streamsfuncs.c      2007-10-09 16:21:41.000000000 +0300
> @@ -608,7 +608,7 @@
>         zval **elem, **dest_elem;
>         php_stream *stream;
>         HashTable *new_hash;
> -       int this_fd, ret = 0;
> +       long this_fd, ret = 0;
>  
>         if (Z_TYPE_P(stream_array) != IS_ARRAY) {
>                 return 0;
>
> regards,
> Margus Kaidja

Closing in favor of #42682 which has more information (no need to have two reports about same issue)