[PEAR-BUG] Bug #19964 [Opn->Csd]: Memory leaking in Archive_Tar

[email protected]
Newsgroups php.pear.bugs
Message-ID <[email protected]>
Edit report at https://pear.php.net/bugs/bug.php?id=19964&edit=1

 ID:               19964
 Updated by:       [email protected]
 Reported By:      mi+php at aldan dot algebra dot com
 Summary:          Memory leaking in Archive_Tar
-Status:           Open
+Status:           Closed
 Type:             Bug
 Package:          Archive_Tar
 Operating System: Linux
 Package Version:  1.3.11
 PHP Version:      Irrelevant
-Assigned To:      
+Assigned To:      mrook
 Roadmap Versions: 
 New Comment:

-Status:      Open
+Status:      Closed
-Assigned To:
+Assigned To: mrook
This bug has been fixed in SVN.

If this was a documentation problem, the fix will appear on pear.php.net
by the end of next Sunday (CET).

If this was a problem with the pear.php.net website, the change should
be live shortly.

Otherwise, the fix will appear in the package's next release.

Thank you for the report and for helping us make PEAR better.




Previous Comments:
------------------------------------------------------------------------

[2014-07-07 21:21:44] mrook

-Roadmap Versions:
+Roadmap Versions: 1.3.12
I've added a workaround in 
https://github.com/pear/Archive_Tar/commit/cffe48226986c3cec680a795fccde83c5
8a05796, which should retain the original functionality when executed on
PHP 4, 
and allow gc on PHP 5. Can you test this? With this change your example
does not 
hit mem limits on my machine.

------------------------------------------------------------------------

[2014-06-07 00:47:31] mi

Perhaps, the destructor could be added conditionally -- if the
PHP-version is determined (at run-time) to be sufficient?

Otherwise, how about re-using the memory? Somehow or other the current
implementation is not suitable for long-running programs, which is a
shame...

------------------------------------------------------------------------

[2014-05-30 15:00:52] mrook

Sorry for taking this long to get back to you.

There are a couple of things going on here:

- Archive_Tar does not have a destructor (at least no __destruct method)
because it 
should remain compatible with PHP 4
- the memory leaking is actually part of static shutdown registration
code in 
PEAR::PEAR() (which is called by Archive_Tar::Archive_Tar())

------------------------------------------------------------------------

[2013-05-29 20:22:01] mi

Description:
------------
Simply creating and unsetting an Archive_Tar object leaks quite a bit of
memory. A long-running program I wrote, that needs to peek inside
tar-files, blows up after a few hours of run-time...

Changing the program to do the peeking by exec-ing tar is my work-around
for the time being.

Test script:
---------------
$i = 0;
if (gc_enabled()) {
	echo("Garbage-collection was enabled already\n");
} else {
	echo("Garbage-collection was not enabled by default. Turning on\n");
	gc_enable();
}

$old_limit = ini_set('memory_limit', '2M');
if ($old_limit == false) {
	echo("Failed to set memory limit to 2M\n");
} else {
	echo("Changed memory limit from $old_limit to 2M\n");
}

while (true) {
	$i++;
	$tar = new Archive_Tar('/dev/zero');
	unset($tar);
	echo("\r$i ");
}

Expected result:
----------------
I expect the test-script to run indefinitely -- or, at least, until the
run-time limit expires.

Actual result:
--------------
Using PHP-5.4 on RHEL-5.7/x86_64 here the script runs to iteration 2047
and then reports:
2047 PHP Fatal error:  Allowed memory size of 2097152 bytes exhausted
(tried to allocate 262144 bytes)

Whether a real tar-file is used or /dev/zero -- it does not matter.
Using a low memory limit simply helps reproduce the problem sooner --
with a limit set to 128M the iterations run to 251363 here, but the
test-script still blows up.

------------------------------------------------------------------------


-- 
Edit this bug report at https://pear.php.net/bugs/bug.php?id=19964&edit=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.