Description: ------------ DB_DataObject 1.7.15 does not free the memory used for caching records after traversing all the records in a query. Even though the man page of free() states that after going through all of the records it should set free the cache, free() has to be called manually in order not to heavily leak memory. If you do not free() manually, it keeps piling up memory usage until it runs into PHP's memory limit. Test script: --------------- while (something) { $dbdo + DB_DataObject::Factory('foo"); $dbdo->find(); while ($dbdo->fetch()) { do_something(); } // $dbdo->free(); // this fixes it. echo memory_get_usage()."\n"; } See http://en.magenson.de/2005/12/14/db_dataobjects-memory-issues/ for an example. Expected result: ---------------- Memory usage of a couple of kilobytes, staying almost the same throughout each while loop (because cached records should be freed after traversal of all of them). Actual result: -------------- An increasing number of memory usage for each loop until the script finally runs into php's memory limit. Can be fixed by using the free() command at the indicated place. However it should do that automatically.

Me too! But I'm on PHP 5. I use many different objects in one test script and it is a nightmare. I'm over 10 Megs in memory for a script.

I also had the same problem with a version of DB_DataObject that was over a year old. This bug has been around for awhile, but not really detected. I remember once someone passing the buck and saying that Date took a lot of ressources, but it seems as if the liberation issue is an important one. If the text in the link is correct, after resolving this issue, the person still had 3.5 megs used after his workaround. Is this due to considerations in the script or other things that could make DB_DataObject bloated ? The importance of resolving this issue seems to be the ability to use DB_DataObject beyond prototypes and in heavy-demand applications.

Okay the 3.5 megs memory usage left are probably part of the framework around the DataObjects, so that's okay for me. In fact, memory usage does not increase significantly anymore throughout the script if the free() calls are made. And you are right, this issue should be resolved in order to reach production status. If you have to fear to break your whole script everytime you want to use a DB_DataObject, you will probably use a different DB abstraction layer that does not have this problem. Especially because the manual says there was no such problem.

This bug has been fixed in CVS. 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. I think this is due to the resultfields array - it is now cleared after the last fetch.

Please consider releasing a bugfix revision soon. This is a major bug (easily breaking whole scripts, even if the amount of records increases only a little) that should be fixed in the official release ASAP.