php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #32979 socket stream opened with stream_socket_client doesnt work with stream_select
Submitted: 2005-05-08 22:18 UTC Modified: 2008-04-04 16:24 UTC
Votes:15
Avg. Score:4.8 ± 0.5
Reproduced:13 of 13 (100.0%)
Same Version:4 (30.8%)
Same OS:4 (30.8%)
From: mjpph at stardust dot fi Assigned: wez (profile)
Status: Closed Package: Streams related
PHP Version: 5CVS-2006-01-18 (dev) OS: Linux (Fedora Core 3)
Private report: No CVE-ID: None
 [2005-05-08 22:18 UTC] mjpph at stardust dot fi
Description:
------------
Using stream_socket_client or stream_socket_server to open a connection fails to report correct values with stream_select. Using fread to get one byte before stream_select suddenly makes stream_select work as expected.
Without it stream_select returns 0 changed streams even though there is data waiting. Service used as an endpoint is persistent and doesn't close the connection after it's output. PHP is CLI-version.

Reproduce code:
---------------
$c = stream_socket_client("tcp://127.0.0.1:80");
while (1)
{
  $streams = array($c);
  if (stream_select($streams, $write=NULL, $except=NULL, 0, 5000)) {
    print "Data received\n";
  }
}

// IP:Port can be anything which outputs something after connection.

Expected result:
----------------
Text "Data received" after connection and output from the service. The service can be anything which just outputs something right after connect.

Actual result:
--------------
Nothing. stream_select returns 0 even though there is data waiting.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-05-08 22:46 UTC] mjpph at stardust dot fi
Also, adding "fread($c,1);" after stream_socket_client and before the while loop enables correct functionality of the stream_select function from that pont on.
 [2005-05-08 22:50 UTC] mjpph at stardust dot fi
Correction to the previous comment. The fread has to be done before every stream_select to obtain any other value from stream_select other than 0. stream_get_meta_data also reports pending data as 0 before the fread and non-zero value right after the 1 byte fread.
 [2005-05-08 23:06 UTC] mjpph at stardust dot fi
The issue is the same when using stream_socket_server. stream_socket_accept works as expected, but if you select the socket it always returns 0, even if there is a pending connection which would be returned with stream_socket_accept.
 [2005-05-09 01:26 UTC] wez@php.net
Is the server end of the socket talking http?
If not, does it send data to the client immediately upon client connection (without expecting data from the client first)?
If not, stream_select() is working precisely as it should.

Also note that stream_select() tells you only if a read or write would not block, not whether there actually is data pending.
 [2005-05-09 09:51 UTC] mjpph at stardust dot fi
No I used http only as an examply not thinking that it doesn't actually output anything straight away.

I used the example code on several services that output information straight from connect without needing any input from the client. For example port 25 welcome message and several others. Telnet straight away you get a welcome. Use only fgets, you get a welcome. Use the example code, you get nothing. Didn't try anything which actually closes the connection after the output, as this isn't the case with my own implementation either and shouldn't be a requirement anyway.

The case is always the same, fgets would get input straight away but stream_select stays dead no matter how many times it loops and waits. Setting the stream to blocking or non-blocking mode has no effect on stream_select's behaviour on this case. The data in the buffer just stays there and stream_select is completely ignorant about it. So, the read wouldn't block (as I know there is data pending), but even despite that stream_select returns 0 changed streams always. So it thinks that read would block, in reality, it doesn't.

Partly unrelated: I have this code in a script which also selects stdin. The stdin select works as expected, the stream_socket selecting select doesn't. I had a perfectly working implementation with socket-based functions which stalled at the selects right after I changed to stream_socket-based functions.
 [2005-05-26 03:05 UTC] wez@php.net
Worked for me just the other week.
You'll need to convince me with a short self-contained test and strace output to prove it.
 [2005-05-26 16:42 UTC] mjpph at stardust dot fi
I used the reproduce code to connect to my own SMTP server, which by using standard socket functions, telnet or any other method instantly outputs the welcome message when I connect. Just add IP+Port to some SMTP server and it'll work for the test.

Here's the strace:
read(3, "<?\n$c = stream_socket_client(\"tc"..., 8192) = 220
read(3, "", 4096)                       = 0
read(3, "", 8192)                       = 0
close(3)                                = 0
munmap(0x2aaaad2e0000, 4096)            = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
close(3)                                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
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, 1000})
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})
select(4, [3], [], [], {0, 5000})       = 1 (in [3], left {0, 5000})

.. it continues like this until I kill the script. The stream_select() never returns anything. If I do fgets() instead of the stream_select() it returns the SMTP welcome instantly.
 [2005-05-26 16:54 UTC] mjpph at stardust dot fi
New info, I was able to get the reproduce code to actually work as it's intended on a Fedora Core 2 machine with PHP 5.0.0RC3 (cgi) (built: Jun 10 2004 16:56:32). Here's strace of it:

read(3, "<?\n$c = stream_socket_client(\"tc"..., 8192) = 199
read(3, "", 4096)                       = 0
read(3, "", 8192)                       = 0
close(3)                                = 0
munmap(0x2a97e16000, 4096)              = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
close(3)                                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("83.145.20
0.2")}, 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, 5000})
select(4, [3], NULL, NULL, {60, 0})     = 1 (in [3], left {60, 0})

at this point the stream_select returns as intended and script ends.

The reproduce code DOESN'T work with several machines running Fedora Core 3 by using 5.0.4 as well as with 200505260030 dated snapshot. stream_select simply doesn't give me anything. Platform is Fedora Core 3 x86_64 under dual xeon 3.2ghz (Nocona, EM64T) with kernel 2.6.11-1.14_FC3smp on the machines that don't return stream_select() as it should.
 [2005-05-26 16:56 UTC] 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.
 [2005-05-26 17:30 UTC] 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 17:38 UTC] 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:50 UTC] 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 18:54 UTC] wez@php.net
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 19:18 UTC] mjpph at stardust dot fi
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().
 [2005-05-27 09:59 UTC] mjpph at stardust dot fi
Also, all the kernels I've used are different versions of FC3 stock kernels without modifications. As FC3 is quite popular Linux I'd assume that many people will have problems with the new functions when they adopt them. Of course it can be a kernel problem, but it can also be a PHP problem which only exhibits on FC3 or with certain kernel settings, but that's more your field to conclude than mine :)
 [2005-05-27 14:06 UTC] wez@php.net
Have you pasted the script that you're actually running with those straces?
Are you really using the one from your initial post?

 [2005-05-27 14:10 UTC] mjpph at stardust dot fi
Only change has been the service port and sometimes the IP if the actual server doesn't host it's own SMTP. I've tested the SMTP availability with telnet and by using fgets instead of stream_select. So yes, the test code fails on FC3 and works on FC2 when the actual ip:port is changed to point to an available SMTP service.
 [2005-05-27 14:14 UTC] mjpph at stardust dot fi
Also, I run constantly a lot more complex PHP-scripts on both FC2 and FC3 servers, on different kernels and by using normal socket and stream functions. They all function perfectly well. All this seems to point to the new stream_socket functions as stream_select works with all the other streams except the ones opened with stream_socket functions.
 [2005-05-27 15:21 UTC] rasmus@php.net
Whenever I see FC3-specific problems I always suspect SELinux.  Although I don't see how that can affect a select()
 [2005-05-27 16:10 UTC] wez@php.net
*please* paste the exact script you are using that produced those straces.

 [2005-05-27 21:52 UTC] mjpph at stardust dot fi
The strangest thing.. I had time to do some test compiles with the 200505260030 snapshot and I got some working. I took my usual parameters off from configure one by one, after I removed --with-openssl the script started suddenly working. Then I did test compile with ./configure --with-openssl and without any parameters. The one --with-openssl failed the script and the one without it worked just fine. It seems that the openssl support does some havoc which causes the failures. I did proper make clean / make distclean between the compiles and doublechecked the results. Linux is a Fedora Core 3, standard install with development support enabled.

The test script is as follows, the host machine has sendmail running as a test service.

<?
$c = stream_socket_client("tcp://127.0.0.1:25");
while (1)
{
  $streams = array($c);
  if (stream_select($streams, $write=NULL, $except=NULL, 5, 0)) die("Select OK\n");
}
?>

Strace from the working PHP (without any configure parameters):

read(3, "<?\n$c = stream_socket_client(\"tc"..., 8192) = 221
read(3, "", 4096)                       = 0
read(3, "", 8192)                       = 0
close(3)                                = 0
munmap(0x2a97b2c000, 4096)              = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
close(3)                                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
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], [], [], {5, 0})          = 1 (in [3], left {4, 998000})
write(1, "Select OK\n", 10)             = 10
close(3)                                = 0
close(1)                                = 0
close(0)                                = 0

...

Strace from the non-working PHP (only --with-openssl added for configure):

read(3, "<?\n$c = stream_socket_client(\"tc"..., 8192) = 221
read(3, "", 4096)                       = 0
read(3, "", 8192)                       = 0
close(3)                                = 0
munmap(0x2a97b2f000, 4096)              = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
close(3)                                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
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], [], [], {5, 0})          = 1 (in [3], left {4, 998000})
select(4, [3], [], [], {5, 0})          = 1 (in [3], left {5, 0})
select(4, [3], [], [], {5, 0})          = 1 (in [3], left {5, 0})

.. continues until the script is killed
 [2005-05-27 22:05 UTC] mjpph at stardust dot fi
It's too bad that the openssl screws up the stream_select or stream_socket_client in some weird way as I intended to use stream_socket_enable_crypto() with the stream_socket_client() and it's dependant of openssl.
 [2005-05-28 04:39 UTC] wez@php.net
That's the missing piece of the puzzle.
openssl replaces the default tcp transport, but passes through to the default when you don't request ssl.
So, the behaviour should be identical.

Can you run the openssl enabled version under valgrind for me, to see if something is misbehaving?
It'll give me a headstart when I sit down to solve the problem in the morning.

Thanks.
 [2005-05-28 11:03 UTC] mjpph at stardust dot fi
Sure thing, just tell me what to do. I've never even heard of valgrind before, but it seems FC3 comes with one.
 [2005-05-28 11:06 UTC] mjpph at stardust dot fi
I guess you need valgrind --tool=callgrind. Also on another matter, I'm unable to compile the newest CVS on FC3. I get this error even without any configure options : libtool: link: `ext/libxml/libxml.lo' is not a valid libtool object.
 [2005-05-28 11:37 UTC] mjpph at stardust dot fi
A problem. I'm running x86_64 FC3 and PHP and valgrind seems to be able to do 32bit executables only.
 [2005-05-28 11:56 UTC] mjpph at stardust dot fi
Looks like this might also be a x86_64 problem. As I compiled the same exact version on i386 FC3 and got it working even with openssl compiled in.
 [2005-05-30 15:37 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

(the compile error should be fixed, plus it should be more 64bit friendly :)

 [2005-05-30 15:53 UTC] mjpph at stardust dot fi
Ok the latest snapshot compiled cleanly on x86_64. The stream_select() bug is still present in the latest snapshot.
 [2005-05-30 16:33 UTC] sniper@php.net
Can you now check it with valgrind, please?

 [2005-05-30 16:56 UTC] mjpph at stardust dot fi
I could, but I get this:
valgrind: Can only handle 32-bit executables

On a 32bit executable and with openssl stream_select() worked ok. On a 64bit PHP executable it doesn't.
 [2005-05-30 16:58 UTC] mjpph at stardust dot fi
Also trying to compile valgrind on x86_64 results in:
checking for a supported CPU... no (x86_64)
configure: error: Unsupported host architecture. Sorry
 [2005-05-30 21:57 UTC] fox dot 69 at gmx dot net
i experience a similar problem since the latest standard kernel update with yum (host.domain.com point to the main server IP) :

<?
$url="http://host.domain.com";
$fp = fopen ($url,"r");
$buffer=fread($fp,8192);
fclose($fp);
echo $buffer;
?>

booted with kernel-2.6.11-1.14_FC3 package: OK
booted with kernel-2.6.11-1.27_FC3 package: NOT OK (timeout)

NOTE: but only if "host.domain.com" point to the executing host itself - same with "localhost" - for all others it seem to be fine
 [2005-05-30 22:11 UTC] mjpph at stardust dot fi
I haven't had problems with different kernels. Only the combination of x86_64, stream_socket_client() or stream_socket_server(), stream_select() and PHP OpenSSL-support seem to reproduce this every time.
 [2005-07-28 01:50 UTC] lew at mailduct dot com
wez -- the problems reported here are all due to a previously fixed bug which has crept back into PHP.  It has to do with how the PHP library treats EOF under FreeBSD vs Linux.

You worked on this problem previously...  please take a look at the currently active Bug #32858 reported by me, as well as your prior fix in Bug #25649.

Thanks....
Lew Payne
 [2006-01-30 09:41 UTC] stotty at tvnet dot hu
I've done some testing, and this bug is definitely triggered by 64 bit+ SSL support.

Bug triggers:
FC4 64 bit + PHP5.1.2 (configure --with-openssl)
FC4 64 bit + PHP 5.1Jan 29 snapshot (configure --with-openssl)

Bug does not trigger:
FC4 64 bit + PHP 5.1.2 (configure)
FC4 64 bit + PHP 5.1Jan29 snapshot (configure)
FC4 32 bit + PHP 5.1.2 (configure --with-openssl)
FC4 32 bit + PHP 5.0.4-10.5 (stock FC RPM)
 [2006-01-31 23:08 UTC] stotty at tvnet dot hu
I have compared the original socket operations code, and the one in the xp_ssl.x file, and it seems that even in the non-ssl path the code is not identical. 

I have fixed four differences, two of which caused some functions to be called twice, and two of which are casting to *(int*)

I do not claim to know the real cause for the bug, and how these changes fix the problem, but they do, and they make the code more consistent, and faster, so I think they should be committed.

Here is the patch that solves this problem form me (against 5.1.2)

------------------------cut here-----------------------
*** php-5.1.2/ext/openssl/xp_ssl.c	2006-01-01 13:50:10.000000000 +0100
--- php-5.1.2ssl/ext/openssl/xp_ssl.c	2006-01-31 23:00:58.000000000 +0100
***************
*** 188,194 ****
  		} while(retry);
  		
  	} else {
! 		didwrite = php_stream_socket_ops.write(stream, buf, count TSRMLS_CC);
  	}
  	
  	if (didwrite > 0) {
--- 188,195 ----
  		} while(retry);
  		
  	} else {
! 		didwrite = php_stream_socket_ops.write(stream, buf, count TSRMLS_CC);	
! 		return didwrite;
  	}
  	
  	if (didwrite > 0) {
***************
*** 226,231 ****
--- 227,233 ----
  	else
  	{
  		nr_bytes = php_stream_socket_ops.read(stream, buf, count TSRMLS_CC);
+ 		return nr_bytes;
  	}
  
  	if (nr_bytes > 0) {
***************
*** 636,642 ****
  
  		case PHP_STREAM_AS_FD_FOR_SELECT:
  			if (ret) {
! 				*ret = (void*)sslsock->s.socket;
  			}
  			return SUCCESS;
  
--- 638,644 ----
  
  		case PHP_STREAM_AS_FD_FOR_SELECT:
  			if (ret) {
! 				*(int*)ret = (void*)sslsock->s.socket;
  			}
  			return SUCCESS;
  
***************
*** 646,652 ****
  				return FAILURE;
  			}
  			if (ret) {
! 				*ret = (void*)sslsock->s.socket;
  			}
  			return SUCCESS;
  		default:
--- 648,654 ----
  				return FAILURE;
  			}
  			if (ret) {
! 				*(int*)ret = (void*)sslsock->s.socket;
  			}
  			return SUCCESS;
  		default:

------------------------cut here-----------------------
 [2006-08-25 19:19 UTC] stotty at tvnet dot hu
Bug is still present in 5.1.4
 [2007-10-08 05:32 UTC] roberto at spadim dot com dot br
i'm having the same problem with xeon quad core (prolian HP) on linux
socket_select work ok
but stream_select don't work
i will recompile php without openssl and check what happen
 [2007-10-08 05:37 UTC] roberto at spadim dot com dot br
the problem occur with php 5.2.4
 [2007-10-08 06:03 UTC] roberto at spadim dot com dot br
without openssl everythink work ok now, socket and stream
where could i send .php files to develop team check it?
 [2008-03-29 10:01 UTC] stotty at tvnet dot hu
Joe Orton has analyzed the bug and found the root cause, see here:

http://marc.info/?l=php-internals&m=120522857529781&w=2
 [2008-04-04 16:24 UTC] jorton@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

This is fixed in CVS, xp_ssl.c revision 1.36, thanks to stotty@ for the patch.

I've backported it to 5.3.x; will backport to 5.2.x if it's OK with the RM too.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Nov 06 08:01:28 2024 UTC