GRAMPS › GRAMPS - Dev

Re: [pygtk] PyGTK object escapes garbage collection

Classic

List

Threaded

2 messages Options

Benny Malengier

Re: [pygtk] PyGTK object escapes garbage collection

We have some methods that are always called.
See editprimary.py, method _cleanup_on_exit
So this can be used to remove specific links that you notice in garbage collection that provide problems.

Then we had a problem with GUI elements loaded from glade. To fix this, we use the method track_ref_for_deletion in the ManagedWindow.py file.
All windows inherit from ManagedWindow, so the clean_up method will be called, and you see this does a delattr on all elements that are tracked.
As the doc there explains, links to GTK objects cannot be collected for some reason, we remove them, and then it works.

Apart from that, callbacks must also be removed, but that is standard procedure of callback routines. Eg, for GUI to DB callbacks, we have src.gen.callman.CallbackManager.
So, if a person is open in a window, and somewhere else this person changes, then a callback to the person window can be done via this manager. As soon as the person is no longer open in a window, the window must unregister the callback before closing the window.

Benny

2012/4/16 Gerald Britton <[hidden email]>

Benny -- IIRC you were the one who cracked this and solved it. Could you provide a little insight for wes?

---------- Forwarded message ----------
From: Wes Hansen <[hidden email]>
Date: Mon, Apr 16, 2012 at 2:00 PM
Subject: Re: [pygtk] PyGTK object escapes garbage collection
To: [hidden email]

Hello Gerald,

I came across your response in the pygtk mailing list in regards to a problem with closeable notebook tabs escaping garbage collection posted a couple years ago. Link.

I too have come across this same issue that the orignal poster described, and I was curious as to your response:

We encountered this problem in our project (gramps-project.org). It
took quite a bit of work to remove the refs to allow GC. Basically, we
added code to track the callbacks then, when the objects were deleted,
added code to explicitly remove them (delete them or set them to None)
to break the cyclical refs. Also, we added code to delete (or set to
None) attributes that might possibly be involved in the cycle.
It was a lot of work but we eventually stopped the memory leaks.
Still, I believe that pygtk could be a LOT smarter in this regard. I
think that what we had to do amounts to fixing a serious design issue
in pygtk.

How exactly did you go about tracking the callbacks and removing them? In my application, in the callback that's fired up when the 'close' button is clicked, I pass a reference to the page( so you know which page is in question),

get its tab_label, explicitly destroying the tab_label widget's children, and disconnecting the close button's signal connection( via its handler id). And then I remove the page from the notebook, and destroy the page.

Doing all of these things doesn't seem to help at all, the page doesn't get garbage collected as there's still references to it. What can I do to free the references to this object?

Also, I tried to look through the source code of your open-source project, gramps, through sourceforge, and I couldn't seem to figure out where exactly you ran into this issue and solved it. I was curious if you knew

which file(s) the issue was solved in?

I appreciate any suggestions or comments.
Thanks for your time,

Wes

--
Gerald Britton

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

jerome

Re: [pygtk] PyGTK object escapes garbage collection

There was also an entry on blog:

http://gramps-project.org/2010/11/memory-leaks-finally-gone/

--- En date de : Mar 17.4.12, Benny Malengier <[hidden email]> a écrit :

De: Benny Malengier <[hidden email]>
Objet: Re: [Gramps-devel] [pygtk] PyGTK object escapes garbage collection
À: "Gerald Britton" <[hidden email]>, "Wes Hansen" <[hidden email]>
Cc: "Gramps Development List" <[hidden email]>
Date: Mardi 17 avril 2012, 9h42

We have some methods that are always called.
See editprimary.py, method _cleanup_on_exit
So this can be used to remove specific links that you notice in garbage collection that provide problems.

Then we had a problem with GUI elements loaded from glade. To fix this, we use the method track_ref_for_deletion in the ManagedWindow.py file.

All windows inherit from ManagedWindow, so the clean_up method will be called, and you see this does a delattr on all elements that are tracked.
As the doc there explains, links to GTK objects cannot be collected for some reason, we remove them, and then it works.

Apart from that, callbacks must also be removed, but that is standard procedure of callback routines. Eg, for GUI to DB callbacks, we have src.gen.callman.CallbackManager.
So, if a person is open in a window, and somewhere else this person changes, then a callback to the person window can be done via this manager. As soon as the person is no longer open in a window, the window must unregister the callback before closing the window.

Benny

2012/4/16 Gerald Britton <[hidden email]>

Benny -- IIRC you were the one who cracked this and solved it. Could you provide a little insight for wes?

---------- Forwarded message ----------
From: Wes Hansen <[hidden email]>

Date: Mon, Apr 16, 2012 at 2:00 PM
Subject: Re: [pygtk] PyGTK object escapes garbage collection
To: [hidden email]

Hello Gerald,

I came across your response in the pygtk mailing list in regards to a problem with closeable notebook tabs escaping garbage collection posted a couple years ago. Link.

I too have come across this same issue that the orignal poster described, and I was curious as to your response:

We encountered this problem in our project (gramps-project.org). It
took quite a bit of work to remove the refs to allow GC. Basically, we

added code to track the callbacks then, when the objects were deleted,
added code to explicitly remove them (delete them or set them to None)
to break the cyclical refs. Also, we added code to delete (or set to

None) attributes that might possibly be involved in the cycle.

It was a lot of work but we eventually stopped the memory leaks.
Still, I believe that pygtk could be a LOT smarter in this regard. I
think that what we had to do amounts to fixing a serious design issue

in pygtk.
How exactly did you go about tracking the callbacks and removing them? In my application, in the callback that's fired up when the 'close' button is clicked, I pass a reference to the page( so you know which page is in question),

get its tab_label, explicitly destroying the tab_label widget's children, and disconnecting the close button's signal connection( via its handler id). And then I remove the page from the notebook, and destroy the page.

Doing all of these things doesn't seem to help at all, the page doesn't get garbage collected as there's still references to it. What can I do to free the references to this object?

Also, I tried to look through the source code of your open-source project, gramps, through sourceforge, and I couldn't seem to figure out where exactly you ran into this issue and solved it. I was curious if you knew

which file(s) the issue was solved in?
I appreciate any suggestions or comments.Thanks for your time,
Wes

--
Gerald Britton

-----La pièce jointe associée suit-----

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
-----La pièce jointe associée suit-----

_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel