|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #40735 stream_select returns 0 for php > 5.1.6
Submitted: 2007-03-05 22:39 UTC Modified: 2007-11-21 12:04 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: rodricg at sellingsource dot com Assigned:
Status: Not a bug Package: Streams related
PHP Version: 5.2.3 OS: x86_64 GNU/Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
5 - 4 = ?
Subscribe to this entry?

 [2007-03-05 22:39 UTC] rodricg at sellingsource dot com
Since php 5.2.0 stream_select fails to return the number of modified descriptors on a 64bit Linux OS (32bit seems to be immune to this).  Verified to exist in the php-snap php5.2-200703052130.

This bug is the same as #40458 but I am unable to modify the status of that bug.

Reproduce code:
$sock = stream_socket_client('tcp://', $eno, $estr, 10, STREAM_CLIENT_CONNECT);
stream_set_blocking($sock, 0);

$r = $w = array($sock);
$n = stream_select($r, $w, $e = NULL, 10);

echo "Selected: {$n}\n";
echo "Read: ", print_r($r,1);
echo "Write: ", print_r($w,1);

Expected result:
Selected: 2
Read: Array
    [0] => Resource id #5
Write: Array
    [0] => Resource id #5

Actual result:
Selected: 0
Read: Array
    [0] => Resource id #5
Write: Array
    [0] => Resource id #5


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2007-03-05 22:47 UTC]
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

 [2007-03-05 23:05 UTC] rodricg at sellingsource dot com
What information can I provide to help determine the cause of this 
problem on my system? Thanks!
 [2007-03-05 23:12 UTC]
An SSH account would be helpful.
 [2007-03-06 00:54 UTC] rodricg at sellingsource dot com
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!
 [2007-03-06 11:24 UTC]
I still get the expected result even with --with-curlwrappers.
 [2007-03-06 21:08 UTC] rodricg at sellingsource dot com
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.
 [2007-03-06 21:14 UTC]
Try with GCC 4.1.2.
GCC 4.1.1 is known to have some problems.
 [2007-03-12 16:54 UTC] rodricg at sellingsource dot com
Same behavior with gcc 4.1.2.  I'm chalking this up to gcc 
optimization and will compile with -O1 for now.
 [2007-03-13 11:05 UTC]
I still have no idea how to replicate it.
 [2007-03-13 16:26 UTC] rodricg at sellingsource dot com
The following script reproduces the behavior (for me):

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

gcc version 4.1.2
openssl version 0.9.8d
 [2007-03-13 19:24 UTC]
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.
 [2007-03-16 23:06 UTC]
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.
 [2007-08-03 21:12 UTC] blade at debian dot org
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 .
 [2007-08-03 22:42 UTC] rodricg at sellingsource dot com
Just verified that I still see the same behavior with:

I am using the same test script as before.  

Changing it to use:

-O1 --with-openssl
-O2 --without-openssl
gives the correct behavior.
 [2007-08-15 08:26 UTC]
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. :)
 [2007-10-29 07:15 UTC] patrick at chegg dot com
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 email. Recompiling with -O1 did NOT solve the problem for me.
 [2007-10-30 20:44 UTC] rodricg at sellingsource dot com
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 
> 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
 [2007-11-21 12:04 UTC]
Closing in favor of #42682 which has more information (no need to have two reports about same issue)

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jun 23 06:01:30 2024 UTC