Memory going wild is not the same things as leaks. Leaks mean than the memory is not freed at the end of a script.

Can you tell me if it is a leak or simply using a lot of memory?

The later is normal if you use the old API. If you only want to extract the files, I recommand to use the new OO API. If you want to extract/and resize, check the stream example, you can open an image in a zip Archive directly from GD (see odt.php for a zip:// example).

You have examples in the package itself (available at pecl.php.net/zip) or from cvs (http://cvs.php.net/viewvc.cgi/pecl/zip/examples/)

Sorry, English is not my native language.
I really mean I have memory leaks, because the memory used by apache processes is never freed, even when nobody acesses the server.
I'll check the zip:// stuff anyway, didn't see that before :o)

Hm, I did not notice any leak in these functions. All data used by the zip function are freed.

Au cas ou, tu peux me mailer en prive (pierre dot php at gmail.com) si c'est plus simple pour toi en francais :)

So, what's next ? How can we check it's a real memory leak (or not) ?
BTW, I'll be away for 3 weeks, but you can send me the tests, I'll run them when I'm back.

Et je vais continuer en anglais si ca ne te gene pas, ca me fait un bon exercice ! Je vais juste me chercher dans un bon dico la definition exacte de l'expression "going wild" ;o)

To check leaks, you can run your code on the console, for example using CLI, with a php version compiled with the debug options (--enable-debug) and the zend memory managed enabled (it is by default).

If the memory is not freed, php will output errors on exit.

An alternative is to disable the zend memory manager and run your scripts through valgrind (valgrind php yourscript.php).

I use both methods before any zip release, I did not notice any leaks :P

Compile ??? I'm under windows here (sorry it's not my fault, I swear). Both methods you describe imply a re-compilation of php, but we don't own any visual C++ (not counting the fact that my sysadmin would probably kill me if he catches me doing that on an in-production server)

You can fetch debug builds on http://snaps.php.net

Also, if you give me an example zip (please not 300MB :) and a script to reproduce your problem, I can take a look.

Right, I'll send you one of the zip files (It's 64Mb, I'll upload it somewhere, and I'll email you the address) and an extract of the scripts (in 3 weeks, as I said before).
One specific point in my case is that I have more than 200 people accessing a single big zip file in a short period. Maybe the concurrent accesses put some trouble in the memory management ?

If you have 200 users accessing the *same* zip archive in the same laps of time, I think you have a design problem.

Why ? 200 people reading the same web page, or viewing the same image at the same time is quite common. Why would it be strange to do the same thing with a resource enclosed in a zip archive ?
The site is a small web publishing system (on an intranet). Users may publish an article with an optional attachment. If this attachment is a zip containing images, they are displayed as a photo gallery (with on-the-fly generated thumbnails). Okay it's quite cpu-intensive, but speed optimization is never a concern here.
the file functions of php can open and read the same file multiple times simultaneously (yes I did it too...), so why wouldn't it work for zip ?

It is normal to have 200 users reading the same page at the same time. It is slightly less normal to have 200 users accessing the same zip archive. You should extract and use  its contents instead of accessing the zip archive endlessly.

However, regarding the possible leaks, they should not exist. Let me know once you have managed to reproduce them (with the php errors, debug mode), or when you have a small script and an example zip.