c2c-oerpscenario team mailing list archive

["tfr \(Openerp\)" <575018@xxxxxxxxxxxxxxxxxx>]

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 C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
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.