good article, esp. the The trouble with Finalizers part
2011/1/10 ron_m ron.mco...@gmail.com:
In the sample code if one comments out the __del__ method in the class the
leak does not occur. That is not to say it can't happen I suppose in a more
complicated code example but I believe the
Yes. For the record, having this class:
class A:
def __init__(self): self.x=x
def __del__(self): pass
and doing this in an action
a=A()
would cause the same leak on ANY web framework running on CPython (not
on Jython).
Using __del__ in python is dangerous.
On Jan 10, 3:15 am,
On Sunday, January 9, 2011 12:59:47 AM UTC-5, ron_m wrote:
To get the leak the __del__method has to be in the class. The gc.collect()
as suggested by Massimo cured the leak for the exec code case I believe
because gc.collect() runs a test on the objects to see if there are any
external
correct.
On Jan 9, 1:18 pm, Anthony abasta...@gmail.com wrote:
On Sunday, January 9, 2011 12:59:47 AM UTC-5, ron_m wrote:
To get the leak the __del__method has to be in the class. The gc.collect()
as suggested by Massimo cured the leak for the exec code case I believe
because gc.collect()
On Jan 9, 2011, at 1:20 PM, Massimo Di Pierro wrote:
correct.
Isn't the need to call gc.collect() explicitly a bit of a puzzle? Or is it just
speeding up something that would happen eventually?
On Jan 9, 1:18 pm, Anthony abasta...@gmail.com wrote:
On Sunday, January 9, 2011 12:59:47 AM
It is a bit of a puzzle to me.
On Jan 9, 3:34 pm, Jonathan Lundell jlund...@pobox.com wrote:
On Jan 9, 2011, at 1:20 PM, Massimo Di Pierro wrote:
correct.
Isn't the need to call gc.collect() explicitly a bit of a puzzle? Or is it
just speeding up something that would happen eventually?
In the sample code if one comments out the __del__ method in the class the
leak does not occur. That is not to say it can't happen I suppose in a more
complicated code example but I believe the __del__ is a required piece. This
test was performed without the gc.collect() being present. I ran
Is there any value in this article for your case?
http://code.activestate.com/recipes/519621-object-finalization-without-__del__-and-without-ha/
Ron
The change in trunk fixes the problem for every class that does not
have a __del__ attribute. Classes that have a __del__ attribute may
cause a memory leak (on cpython, not on jython).
On Jan 7, 11:41 pm, Anthony abasta...@gmail.com wrote:
As far as I can tell, the change in trunk didn't have
Without actually trying it, but it still seems the cause for memory
leak of (A) and (B) is different. (B) is a case of circular reference,
and as such reference counting garbage collection (cpython) will fail
to work properly.
But (A), which is the leak in web2py, does not seem to related to
I don't get why there is a problem. I did a scan of the latest trunk and did
not find a __del__ function anywhere.
If the sample code is run with the __del__ it accumulates memory rapidly.
Comment out the __del__ method which does nothing in this example and the
memory accumulation is no
Sorry, I wasn't paying attention -- I had put the code in there prior to the
issue about __del__ being raised. The leak is now gone in my testing.
Thanks.
Anthony
On Saturday, January 8, 2011 10:43:13 AM UTC-5, Massimo Di Pierro wrote:
The change in trunk fixes the problem for every class
Two ingredients case a memory leak in ANY python program: __del__ and
circular references. You need them both.
In the case of web2py exec code in {} creates the circular reference
for objects defined in the code. This does not mean web2py has a
memory leak. In fact, as pointed out, no web2py
On Saturday, January 8, 2011 5:48:06 PM UTC-5, Massimo Di Pierro wrote:
Two ingredients case a memory leak in ANY python program: __del__ and
circular references. You need them both.
In the case of web2py exec code in {} creates the circular reference
for objects defined in the code.
On Jan 8, 2011, at 2:48 PM, Massimo Di Pierro wrote:
In the case of web2py exec code in {} creates the circular reference
for objects defined in the code.
What is the circular reference?
def f(): pass
...
f.func_globals
{'A': class __main__.A at 0x465d20, 'a': __main__.A instance at
0x470260, 'f': function f at 0x46a630, '__builtins__': module
'__builtin__' (built-in), '__name__': '__main__', '__doc__': None}
globals()
{'A': class __main__.A at 0x465d20, 'a': __main__.A
Thanks for the extra explanation.
You have to have a __del__ method in the class to get the leak
To get the leak the __del__method has to be in the class. The gc.collect()
as suggested by Massimo cured the leak for the exec code case I believe
because gc.collect() runs a test on the objects to see if there are any
external references, finds none, and therefore allows them to be removed
Actually this works for all classes but classes that have a __del__
(and this is not a web2py specific problem) so for now:
Attention: do not define classes with a __del__ method in models or
controllers.
Even if you do not use web2py but use another framework, do not create
classes with __del__
More about the subject of circular references:...
http://www.jython.org/archive/21/docs/differences.html
In Jython users don't need to worry about handling circular
references as these are guaranteed to be collected properly
CPython uses reference counting instead of proper garbage collection
As far as I can tell, the change in trunk didn't have any effect for me. I'm
on Windows 7 with Python 2.7.1 (just using the built-in Rocket server). I
added the following code to the top of default.py (outside any functions) in
the welcome app:
class Foo(object):
def __del__(self):
Also, I noticed the changeset in trunk included main.py and restricted.py,
but there were no actual changes in restricted.py. Was there supposed to be
a change in restricted.py that was mistakenly left out?
On Saturday, January 8, 2011 12:41:27 AM UTC-5, Anthony wrote:
As far as I can tell,
Doesn't adding the gc.collect() just force the garbage collector to run
right now instead of waiting until some usage threshold is crossed and then
it runs to do the cleanup at some time in the future. Any accumulation of
heap use until gc gets around to running isn't really a leak, it is just
24 matches
Mail list logo
