[pygtk] PyGObject leaking?

[Tony Nelson]

At 10:54 PM -0400 4/10/07, Mario Beauchamp wrote:
>Hi folks,
>
>On 4/10/07, Tony Nelson <tonynelson at georgeanelson.com> wrote:
>>
>> Cyclic garbage can be viewed as an error in the data structure, preventable
>> by either breaking the cycle manually when the object is expected to become
>> unreferenced, or by using weak references.
>
>The previous code used weak references but it was not doing the job
>either so I got rid of it. "They" had an object derived from pygobject
>here:
>http://openev.svn.sourceforge.net/viewvc/openev/trunk/src/pymod/gvobject.py?revision=6&view=markup

Well, the rot may be deeper than that, inside pygobject or pygtk code. ;)
(I can't make heads or tails of that code, sorry if I am slandering it.)


>On 4/10/07, Johan Dahlin <jdahlin at async.com.br> wrote:
>>
>> It's not recommended to call gc.collect() in production code, unless it's
>> absolutely necessary. It's quite expensive to call it and in most cases not
>> really needed. In most cases it's fine to wait until Python decides to
>>call it.
>
>I think it is absolutely necessary as my objects can occupy a huge
>amount of RAM or keep a file open that I want to be closed. And when I
>need them to be freed, I cannot afford to wait for the next collect.
>But I think only a few gc.collect() calls strategically placed will be
>necessary after all.

Python will collect objects as soon as they become unreferenced.
Immediately.  If you rely on Cyclic GC, your code has the bug of reference
loops.  As I said, I haven't had this problem since I don't make reference
loops; objects in my programs are freed immediately and their memory is
made available again.

There are GC tools to show you which objects are garbage.  Those are the
objects that are in or are referred to by reference loops.


>And I think a bit of history would help everyone understand what I am
>trying to do so here goes:
>
>OpenEV is a pygtk-based application for viewing and interacting with
>geospatial data like satellite imagery and vector data. It is listed
>under "Scientific Applications" on
>http://www.pygtk.org/applications.html.
>
>It was developed originally (circa 2000) by Atlantis Scientific and
>others. The current production version is based on pygtk 0.6.x. In
>2005, Atlantis Scientific (then called Vexcel) began the GTK2 port of
>the software. But in May 2006, they were bought by Microsoft,
>therefore signifying the end of their contribution to OpenEV.
>
>I then became an OpenEV admin with the mandate to complete this task.
>However at the time, I thought I would only have to deal with the
>Python part. But I had to learn the rest in the last month or so
>because it was necessary. You can see the changes (or mistakes!) I
>have made since here:
>http://openev.svn.sourceforge.net/viewvc/openev/trunk/src
>
>Thanks for your patience :)

FWIW, it might help to try to recreate some of the problems in small test
code of your own.  Learning how to make them happen intentionally the way
the original code does it might lead to a solution, except for perhaps any
pygobject issues.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>