#21760 [Ver->Csd]: socket_read PHP_NORMAL_READ problem

ID: 21760 Updated by: iliaa@php.net Reported By: sunday at csh dot rit dot edu -Status: Verified +Status: Closed Bug Type: Sockets related Operating System: FreeBSD 4.7 PHP Version: 4.3.0 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2004-02-24 08:43:13] eriksson@php.net 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 iliaa@php.net 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 iliaa@php.net 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. Regards, David Eriksson ------------------------------------------------------------------------ [2003-02-27 10:16:20] iliaa@php.net Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Works fine here with latest stable CSV. The path you prose is bogus because it overwrites the 1st byte in t with a 0. ------------------------------------------------------------------------ [2003-02-05 21:13:53] chip at cyan dot com ah. found my windows 2000 socket_read bug: http://bugs.php.net/bug.php?id=21197 ------------------------------------------------------------------------ [2003-02-05 21:08:07] chip at cyan dot com I can repeat this bug. here is an example script that i used: http://force-elite.com/~chip/test/socket_phpreadnormal.phps it is a modification of the basic HTTP client given as an example in the PHP.net 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 09:53:04] 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). Patch: --- 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 @@ set_errno(0); + *t = 0; while (*t != '\n' && *t != '\r' && n < maxlen) { if (m > 0) { t++; ------------------------------------------------------------------------ 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/21760 -- Edit this bug report at http://bugs.php.net/?id=21760&edit=1