|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21760 socket_read PHP_NORMAL_READ problem
Submitted: 2003-01-19 23:18 UTC Modified: 2004-02-25 17:04 UTC
Avg. Score:4.9 ± 0.2
Reproduced:36 of 36 (100.0%)
Same Version:13 (36.1%)
Same OS:21 (58.3%)
From: sunday at csh dot rit dot edu Assigned:
Status: Closed Package: Sockets related
PHP Version: 4.3.0 OS: FreeBSD 4.7
Private report: No CVE-ID: None
 [2003-01-19 23:18 UTC] sunday at csh dot rit dot edu
$string = socket_read( $socket, 100, PHP_NORMAL_READ ); will return a "\n" after several reads, and continue to return "\n" in an infinite loop rather than the rest of the buffer.

The server it's reading from sends a large multi-line (lines terminated with "\n") packet (~7500 bytes) in one write() call. After reading through about half of it with the line above, socket_read will start returning bad data about 10% - 20% of the time.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-05 09:53 UTC] uce at ftc dot gov
I believe this is caused by a comparison to an uninitialized buffer in php_read (buffer emalloc'd in socket_read).


--- php5/ext/sockets/sockets.c  2003-01-18 19:28:06.000000000 +0000
+++ php5-atropine/ext/sockets/sockets.c  2003-02-05 15:43:00.000000000 +0000
@@ -288,6 +288,7 @@
+       *t = 0;
        while (*t != '\n' && *t != '\r' && n < maxlen) {
                if (m > 0) {
 [2003-02-05 21:08 UTC] chip at cyan dot com
I can repeat this bug.

here is an example script that i used:

it is a modification of the basic HTTP client given as an example in the documentation.

When PHP_NORMAL_READ is used, and certen buffer sizes, it will resuilt in socket_read returning bogus data, commonly all newlines(\n).

On both a FreeBSD-4.7-stable(built Fri Nov 29), and FreeBSD-5.0-RC(built Wed Jan 8), both using PHP-4.3.0-cli, with a buffer size of 2048 it would work, with a buffer size of 100, socket_read() would return a stream of \n.

On Linux 2.4.18-18.7.x(Redhat Box) using PHP-4.3.0-cli, it would always work, regardless of the buffer size.

On Linux 2.4.19-crypto-r7(Gentoo Box) using PHP-4.3.0-cli, it would work with 2048 buffer size, but with 100 it would bail with:
Notice: Undefined offset:  0 in /path/socket_phpreadnormal.php on line 51
Warning: socket_read() expects parameter 1 to be resource,
null given in /path/socket_phpreadnormal.php on line 51
(I don't have direct access to this box, I didn't want to heavly debug it, it is possibly an error in my script.)

On Windows 2000, using PHP-4.3.0-cli, it would always return 0(EOF) from socket_read(). It Bailed with:
Warning: socket_read() unable to read from socket [0]: The operation completed successfully.
(perhaps a seperate bug :-) )
 [2003-02-05 21:13 UTC] chip at cyan dot com
ah. found my windows 2000 socket_read bug:
 [2003-02-27 10:16 UTC]
Please try using this CVS snapshot:
For Windows:

Works fine here with latest stable CSV.
The path you prose is bogus because it overwrites the 1st byte in t with a 0.
 [2004-02-24 08:43 UTC]
I have the same problem with this function with PHP 4.3.4 on FreeBSD 4.9. (The file sockets.c is exactly the same in this version of PHP and in php4-STABLE-200402241230.)

I think the patch suggested by "uce at ftc dot gov" looks like the simplest solution. Contrary to what indicate, this patch does not in any way affect the result returned to the user, except for fixing this bug.

I'm not at all surprised that was unable to reproduce this bug, because it only occurs if the buffer returned by emalloc() in socket_read() begins with '\r' or '\n', and that is not neccessarily the case, depending on configuration and operating system.

I don't think I have commit access to the sockets extension, but I hope that somebody who has can fix this.


David Eriksson
 [2004-02-25 17:04 UTC]
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
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 10:01:28 2024 UTC