I made python print the #refs for alpha and that seems to be increasing
for no reason. My guess is that it was not decremented after sine_func
completed. I don't know much about clutter...
class AnimatedLabel():
def __init__(self):
print 'INIT %s' % self
self.label = clutter.Label()
self.timeline = clutter.Timeline(duration=1000)
self.timeline.set_loop(True)
self.alpha = clutter.Alpha(self.timeline, clutter.ramp_func)
self.behaviour = clutter.BehaviourDepth(alpha=None,
depth_start=0, depth_end=200)
self.behaviour.apply(self.label)
self.timeline.start()
def __del__(self):
print '#alph:', sys.getrefcount(self.alpha)
print '#beh:', sys.getrefcount(self.behaviour)
print '#tim:', sys.getrefcount(self.timeline)
del self.alpha
del self.behaviour
print 'DEL %s' % self
Output:
INIT <__main__.AnimatedLabel instance at 0xb65cee4c>
#alph: 481
#beh: 2
#tim: 2
DEL <__main__.AnimatedLabel instance at 0xb65cee4c>
gc_len: 422295
INIT <__main__.AnimatedLabel instance at 0xb65cee4c>
Traceback (most recent call last):
File "leak5.py", line 59, in <module>
clutter.main()
KeyboardInterrupt
#alph: 2511
#beh: 2
#tim: 2
Obviously alpha is never freed! BTW if you look at alpha.__grefcount__,
that seems to be sane (and it does not agree with python ref count only
for alpha).
Also, sys.getrefcount() returns real_refcount+1
-Ashwin
-----Original Message-----
From: Tero Saarni [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 07, 2008 12:29 PM
To: [email protected]
Subject: Re: [clutter] Memory leak with pyclutter
On Feb 7, 2008 5:54 PM, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> my point, if it wasn't clear - and by now I kinda guessed it really
> wasn't - is that you can avoid leaking by simply *not* doing what you
> are doing, as there are ways to reimplement the same functionality in
a
> safe way.
Yep, you are of course correct.
What I've now learnt is that if I implement widgets in python
inheriting from clutter classes:
- I should not use any of the clutter.effect_*() functions for Actors
implemented in python
- I should not store clutter objects (or any other gobject) to member
variables of python based Actor *if* the object in question holds
reference back to the Actor
breaking these rules causes noncollectable objects.
This still doesn't sound right to me... There must be some general
knowledge about gobject+python which I've just missed... ;-)
Anyway, thanks for your help and for the great library!
--
Tero
--
To unsubscribe send a mail to [EMAIL PROTECTED]
--
To unsubscribe send a mail to [EMAIL PROTECTED]