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.

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())

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...

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.

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.