ID: 40735 User updated by: rodricg at sellingsource dot com Reported By: rodricg at sellingsource dot com Status: Open Bug Type: Streams related Operating System: x86_64 GNU/Linux PHP Version: 5.2.3 New Comment:
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 Previous Comments: ------------------------------------------------------------------------ [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 . ------------------------------------------------------------------------ [2007-03-16 23:06:09] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ 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