Edit report at https://bugs.php.net/bug.php?id=62106&edit=1
ID: 62106
Comment by: a...@php.net
Reported by: t dot glaser at tarent dot de
Summary: zip can (and will, in real-life cases) leak huge
tempfiles
Status: Assigned
Type: Bug
Package: Zip Related
Operating System: Unix/POSIX, maybe Windows
PHP Version: master-Git-2012-05-22 (Git)
Assigned To: ab
Block user comment: N
Private report: N
New Comment:
I'll be working on improving libzip then. But I think, testing the current
patch
would make sense anyway. At least it could prove the code path, despite we
could
pack the improved libzip stuff into a __destruct() or alike.
Previous Comments:
------------------------------------------------------------------------
[2012-07-12 17:53:26] paj...@php.net
hi!
Thanks for the bug report and patch!
I do not like the idea of having php specific function called or used like it
is
in this patch.
Temporary files are created while working with a given archive. These files
should be destroyed when the archive is not used anymore, on resource or object
destroy.
Maybe a function in the zip library could be added for this cleanup.
------------------------------------------------------------------------
[2012-07-12 15:27:42] a...@php.net
Yep, I'd better not start do get all the 5.4 deps on lenny :)
The test code should work also on faster mashines. If not - decreasing the last
set_time_limit(3) or increasing the data amount should work. On
current PHP versions a temp file should be laying around anyway after the
script
has
exited with the time limit warning. I mean even the fastest drive cant get 200M
wrote on it in 3 sec ) . But way much better is of course to test
with your app on a test instance.
The patch should apply to 5.3, 5.4 and master as well.
PHPT are the test case files from the PHP test framework. Such files are
usually
to find in "tests" subfolders inside the PHP source tree. You can read more
under http://qa.php.net .
------------------------------------------------------------------------
[2012-07-12 14:19:32] t dot glaser at tarent dot de
Hum. Unfortunately, I cannot bring a self-compiled PHP into the production
system, especially as it runs Debian lenny still. But within some time, I
should be able to test the patch on Debian wheezy, on a test instance, by
using a self-compiled locally patched source package, as theyâre on 5.4
already.
Your testcase looks sound to exhibit this behaviour on all but the fastest
machines.
I have no idea what phpt is, sorry.
------------------------------------------------------------------------
[2012-07-10 14:20:04] a...@php.net
Please test the supplied patch. Ideally you could do this with your productive
dev environment. Because cleanup happens on request shutdown, looks like it's
nearly impossible to test this with phpt. Consider the following piece of code:
<?php
set_time_limit(0);
ini_set('memory_limit', '768M');
$zip_fname = dirname(__FILE__) . DIRECTORY_SEPARATOR . 'bug62106.zip';
$s = 'a';
foreach (array(1024, 1024, 200) as $b) {
$s = str_repeat($s, $b);
}
$zip = new ZipArchive();
$r = $zip->open($zip_fname, ZipArchive::CREATE);
if ($r) {
$zip->addFromString('huhu.txt', $s);
set_time_limit(3);
$zip->close();
}
register_shutdown_function will not work here because it's a part of request.
But it's clearly to see - without patch there are temp files there, and with
the
patch the cleanup works. But the best were of course if you test it directly
with your app. If you have an idea how to test this with phpt, it would be also
great :)
------------------------------------------------------------------------
[2012-07-10 14:14:00] a...@php.net
The following patch has been added/updated:
Patch Name: 62106.patch
Revision: 1341929640
URL:
https://bugs.php.net/patch-display.php?bug=62106&patch=62106.patch&revision=1341929640
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=62106
--
Edit this bug report at https://bugs.php.net/bug.php?id=62106&edit=1
