Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.11.5

Bug #6247 DB_DataObjects not freeing memory after running through all records
Submitted: 2005-12-14 23:32 UTC
From: fred at osuosl dot org Assigned: alan_k
Status: Closed Package: DB_DataObject
PHP Version: 4.4.0 OS: Linux
Roadmaps: (Not assigned)    
Subscription  


 [2005-12-14 23:32 UTC] fred at osuosl dot org
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.

Comments

 [2005-12-17 17:45 UTC] contact at mann dot fr
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.
 [2005-12-17 18:05 UTC] contact at mann dot fr
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.
 [2005-12-17 19:45 UTC] fred at osuosl dot org
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.
 [2005-12-22 03:12 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2005-12-27 22:56 UTC] fred at osuosl dot org
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.