the fix is released in trunk, I invite you to try and give us feedback -- You received this bug notification because you are a member of OpenERP sa GTK client R&D, which is a bug assignee. https://bugs.launchpad.net/bugs/575018
Title: Client memory leaks and long lists (the list is never freed) Status in OpenObject GTK Client: Fix Released Bug description: The GTK client (the web client may be affected too, see bug 574778) doesn't seem to free the records from the views, making impossible to python to free memory. If a list view (form view in tree mode) with lots of records is shown, it uses a lot of memory (which is expected) that is never freed after the view is closed (ouch!). So, after a while working with the GTK client it consumes all the memory and the system becomes unresponsive (swapping) or dies (out of memory). Note: The size of the list doesn't matter, but obviously you would have to open lots of small (80 records) views for the problem to be noticeable. HOW TO REPRODUCE: - Connect the GTK client to an OpenERP database with a lot of accounting records (any other big list would do the job). On our example we had 20000 account move lines. - Go to "Financial Management -> Reporting -> Search Entries -> Entry Lines". Change the search parameters so all the records (20000) are displayed. It takes a while to load the list (this is expected) and it uses 264MB of memory. - Close the view, disconnect from the server (but don't close the client): No memory is freed!!! (still 264MB). - Open the Entry Lines list and show all the records again => Now the GTK client uses 483MB - Close the Entry Lines view again: No memory is freed! (still 483MB) - Open the Entry Lines view and show all the records again => Now the GTK client uses 692MB - Close the Entry Lines view again: No memory is freed! (still 692MB) ... - Open the Entry Lines view and show all the records again => Swapping... and eventually (if the user does not get bored before) a "not enough memory" error. So, each time the list is shown, a new 220MB of memory are consumed that will never be freed. COMMENTS: We tried forcing the garbage collector to do its job: ipdb> import gc ipdb> gc.get_count() (465, 9, 0) ipdb> gc.collect() 167 ipdb> gc.get_count() (7, 0, 0) ipdb> gc.garbage [] ipdb> len(gc.get_objects()) 1132991 But just an insignificant bit of memory is freed. The length of the objects (gc.get_objects()) grows each time we open a view, but doesn't go down when the view is closed; and the gc.garbace list is not growing. That means that the items from the views (or the whole view) simply aren't being unreferenced when the view is closed. _______________________________________________ Mailing list: https://launchpad.net/~openerp-dev-gtk Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-dev-gtk More help : https://help.launchpad.net/ListHelp
