ID: 40735
Updated by: [EMAIL PROTECTED]
Reported By: rodricg at sellingsource dot com
-Status: Open
+Status: Bogus
Bug Type: Streams related
Operating System: x86_64 GNU/Linux
PHP Version: 5.2.3
New Comment:
Closing in favor of #42682 which has more information (no need to have
two reports about same issue)
Previous Comments:
------------------------------------------------------------------------
[2007-10-30 20:44:39] 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
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
------------------------------------------------------------------------
[2007-10-29 07:15:48] 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 @php.net email. Recompiling with -O1 did NOT solve the problem for me.
------------------------------------------------------------------------
[2007-08-15 08:26:55] [EMAIL PROTECTED]
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-08-03 22:42:15] rodricg at sellingsource dot com
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.
------------------------------------------------------------------------
[2007-08-03 21:12:20] 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
http://netevil.org/blog/2005/may/guru-multiplexing .
------------------------------------------------------------------------
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/40735
--
Edit this bug report at http://bugs.php.net/?id=40735&edit=1
