php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #16148 fread function leaks memory when reading from socket
Submitted: 2002-03-18 12:33 UTC Modified: 2002-03-18 15:15 UTC
From: petri dot valisuo at lmf dot ericsson dot se Assigned:
Status: Closed Package: Sockets related
PHP Version: 4.1.2 OS: SunOS 5.8
Private report: No CVE-ID: None
 [2002-03-18 12:33 UTC] petri dot valisuo at lmf dot ericsson dot se
It seems that fread command leaks memory when data is 
read from a socket. It does not leak memory if it reads 
from open file descriptor. The speed of the process increse is as fast as the data flow, i.e. all bytes 
which are read leaks!

Here is a program that shows the problem. We have a file
server in the port 9229. When connection is opened there
and about 250 MB zip file is requested, the process dies
after it has received 8 MB of data. If the file is read
from an open file, the process size does not increse at
all, and it works perfectly.

<?php
$len=248532882;
header("Content-Type: application/octet-stream");	  
header("Content-Disposition: attachment; filename=file.zip");
header("Content-Length: $len");
$pkg_size=1024;

if(1) {
  $sock=fsockopen("localhost", 9229) or die ("Cannot open socket");
  fputs($sock, "GET file.zip\r\n");
}
else {
  $sock=fopen("file.zip", "r");
}

while(!feof($sock)) { 
  $recv_amount=(($len > $pkg_size) ? ($pkg_size): ($len));
  print fread($sock, $recv_amount);
  $len=$len-$recv_amount;
  if($len<1) break;
}
flush();
fclose($sock);
?>

Here is the configuration command of PHP 4.1.2 we are 
using, as reported by the phpinfo().

'./configure' '--with-apache=../apache_1.3.23' '--with-ldap=/data/usr/iPlanet/ldapcsdk414' '--prefix=/data' '--enable-memory-limit'


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-03-18 15:15 UTC] wez@php.net
This bug has been fixed in CVS.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 14:01:32 2024 UTC