ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
-Status: Feedback
+Status: Open
Bug Type: Network related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
Assigned To: wez
New Comment:
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().
Previous Comments:
------------------------------------------------------------------------
[2005-05-26 18:54:13] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[2005-05-26 17:50:51] mjpph at stardust dot fi
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?
------------------------------------------------------------------------
[2005-05-26 17:38:20] mjpph at stardust dot fi
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.
------------------------------------------------------------------------
[2005-05-26 17:30:16] mjpph at stardust dot fi
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.
------------------------------------------------------------------------
[2005-05-26 16:56:43] mjpph at stardust dot fi
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.
------------------------------------------------------------------------
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/32979
--
Edit this bug report at http://bugs.php.net/?id=32979&edit=1
