php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #32255 memory leak in fopen wrappers ?
Submitted: 2005-03-09 16:16 UTC Modified: 2005-06-28 01:00 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: antoine dot bajolet at tdf dot fr Assigned:
Status: No Feedback Package: HTTP related
PHP Version: 5CVS, 4CVS (2005-03-14) OS: Linux 2.4.29
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: antoine dot bajolet at tdf dot fr
New email:
PHP Version: OS:

 

 [2005-03-09 16:16 UTC] antoine dot bajolet at tdf dot fr
Description:
------------
It seems that there is a memory leak in fopen wrappers to HTTP.

With a minimal compilation of PHP :

./configure --disable-all --enable-sockets --without-pear --enable-memory-limit --without-pcre-regex --without-mysql

And the first code above, the memory used increased continuously.

(the -n flag is used to ignore any php.ini script. All parameters are default).

#sapi/cli/php -n script1.php
12160
13536
13672
13736
13800
13864
13928
13992
14056
14120
14184
... still increasing

With a classic fopen, works fine
#sapi/cli/php -n script2.php
12128
12320
12336
12336
12336
12336
12336
12336
12336
12336
12336
... still stable

This is very annoying because we are writing a small php daemon using periodics requests on HTTP hosts.

For more infos :
#ldd sapi/cli/php                                                  libcrypt.so.1 => /lib/libcrypt.so.1 (0x4001b000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40049000)
        libm.so.6 => /lib/i686/libm.so.6 (0x4005b000)
        libdl.so.2 => /lib/libdl.so.2 (0x4007d000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40081000)
        libc.so.6 => /lib/i686/libc.so.6 (0x40096000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

/lib/libcrypt.so.1 -> libcrypt-2.3.2.so
/lib/libresolv.so.2 -> libresolv-2.3.2.so

Regards
Antoine Bajolet



Reproduce code:
---------------
With this, memory problem :

<?php
/* script1.php */
while(true){
	echo memory_get_usage()."\n";
	$handler = fopen('http://some.thing/','r');
	fclose($handler);
	sleep(2);
} // while
?>

With this, no memory problem

<?php
/* script2.php */
while(true){
	echo memory_get_usage()."\n";
	$handler = fopen('/etc/hosts','r');
	fclose($handler);
	sleep(2);
} // while
?>


Expected result:
----------------
The memory used has to be stable, not increasing.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-03-10 13:05 UTC] antoine dot bajolet at tdf dot fr
I retried on another machine, with an older linux installation -> No memory leak.

The problem appears on an RH9 (glibc-2.3.2)
But not on Mandrake 8.1 (glibc-2.2.4)

Trying to update the RH9 glibc (an update exists).
 [2005-03-11 14:57 UTC] antoine dot bajolet at tdf dot fr
Problem still persists with :
- RH9 glibc update (glibc-2.3.2-27.9.7)

- Php4 stable snapshot (php4-STABLE-200503111130)
OR php-5.0.3.

It seems not to be the resolve part of the wrapper : same test script with a simple gethostbyname() don't leaks memory.

Here is a strace of one loop (if it helps)

nanosleep({2, 0}, {2, 0})               = 0
write(1, "14264\n", 614264
)                  = 6
socket(PF_UNIX, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
open("/etc/hosts", O_RDONLY)            = 3
fcntl64(3, F_GETFD)                     = 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=160, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000
read(3, "127.0.0.1              localhost"..., 4096) = 160
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x40016000, 4096)                = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("32.2.32.10")}, 28) = 0
send(3, "\257\1\1\0\0\1\0\0\0\0\0\0\5rpnet\10intranet\3tdf\2"..., 39, 0) = 39
gettimeofday({1110548703, 854413}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(3, FIONREAD, [123])               = 0
recvfrom(3, "\257\1\205\200\0\1\0\2\0\1\0\1\5rpnet\10intranet\3tdf\2"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("32.2.32.10")}, [16]) = 123
close(3)                                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("32.23.32.105")}, 16) = 0
send(3, "GET / HTTP/1.0\r\n", 16, 0)    = 16
send(3, "Host: rpnet.intranet.tdf.fr\r\n", 29, 0) = 29
send(3, "\r\n", 2, 0)                   = 2
select(4, [3], NULL, NULL, {0, 0})      = 0 (Timeout)
select(4, [3], NULL, NULL, {60, 0})     = 1 (in [3], left {59, 940000})
recv(3, "HTTP/1.1 200 OK\r\nDate: Fri, 11 M"..., 8192, 0) = 1448
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0},  <unfinished ...>

Can it be a bug of gcc (mdk8.1 -> 2.96, RH9 -> 3.2.2) ?
 [2005-06-20 12:28 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

And upgrade your glibc to something more recent. I can't reproduce this with glibc 2.3.4
 [2005-06-28 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 13 18:01:28 2024 UTC