Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Why is this a mem leak?

Reply
Thread Tools

Why is this a mem leak?

 
 
Steve
Guest
Posts: n/a
 
      07-22-2004
Hi,

I saw an article online
(http://aspn.activestate.com/ASPN/Coo...n/Recipe/65333) where it
explains how one can find out if there's a memory leak in ones program.
How is there a memory leak in this:

# make a leak
l = []
l.append(l)
del l

??? Shouldn't deleting an object explicitly give the GC a better chance
to find the object? Won't deleting it cause it's reference to go down
(another question: which GC is python 2.3 using? Refcount or
Generational?). Isn't 'del' similar to 'free'ing in C??

Thanks,

Steve

 
Reply With Quote
 
 
 
 
Steve
Guest
Posts: n/a
 
      07-22-2004

Steve wrote:
> Hi,
>
> I saw an article online
> (http://aspn.activestate.com/ASPN/Coo...n/Recipe/65333) where it
> explains how one can find out if there's a memory leak in ones program.
> How is there a memory leak in this:
>
> # make a leak
> l = []
> l.append(l)
> del l
>
> ??? Shouldn't deleting an object explicitly give the GC a better chance
> to find the object? Won't deleting it cause it's reference to go down
> (another question: which GC is python 2.3 using? Refcount or
> Generational?). Isn't 'del' similar to 'free'ing in C??
>
> Thanks,
>
> Steve
>


Another question:

I get the following when I set DEBUG in gc to DEBUG_LEAK:

GARBAGE:
gc: uncollectable <JCollector instance at 0x403a7f2c>
gc: uncollectable <NCollector instance at 0x403fa2cc>
gc: uncollectable <dict 0x403a9c64>
gc: uncollectable <dict 0x403f9934>
gc: uncollectable <instancemethod 0x403a5dec>
gc: uncollectable <instancemethod 0x403aa0f4>

this was after calling a method foo() which created two instances of a
single class, which then created the dictionaries and instancemethods
named above. After foo() ended, I would have thought that these
instances/objects would have been collected. I called gc.collect()
explicitly two times but the gc.garbage list still held the same list as
'garbage'. Does 'uncollectable' here means that these objects will never
be collected? Why is that? They're not bound by anything once foo()
exits. How can I make sure the memory allocated for this junk is deleted
(since I want to run foo() in a loop). Can someone please tell me what's
happening? Thanks,

Steve

 
Reply With Quote
 
 
 
 
jepler@unpythonic.net
Guest
Posts: n/a
 
      07-23-2004
(The below message confuses Python, the language, with the CPython 2.3
implementation)

In the absence of gc, l will never be collected. (well, "the thing l once
named", since it won't name anything directly after the "del" statement)

with cyclic GC plus refcounting, including Python 2.3 when built in the
default way, l will be collected.

"del l" has the effect of making the name "l" no longer refer to anything
and of decreasing the reference count of that object by 1. It does not
relate directly to C's free() or C++'s delete, because those release
the storage underlying the object, even if pointers to that object still
exist elsewhere in the program. CPython only releases the underlying
storage for the object when the refcount reaches 0, with "GC" being used
to find unreachable cycles and deal with them in some other way.

Jeff
 
Reply With Quote
 
Tim Peters
Guest
Posts: n/a
 
      07-23-2004
[Steve <(E-Mail Removed)>]
....
> Another question:
>
> I get the following when I set DEBUG in gc to DEBUG_LEAK:
>
> GARBAGE:
> gc: uncollectable <JCollector instance at 0x403a7f2c>
> gc: uncollectable <NCollector instance at 0x403fa2cc>
> gc: uncollectable <dict 0x403a9c64>
> gc: uncollectable <dict 0x403f9934>
> gc: uncollectable <instancemethod 0x403a5dec>
> gc: uncollectable <instancemethod 0x403aa0f4>
>
> this was after calling a method foo() which created two instances of a
> single class, which then created the dictionaries and instancemethods
> named above. After foo() ended, I would have thought that these
> instances/objects would have been collected. I called gc.collect()
> explicitly two times but the gc.garbage list still held the same list as
> 'garbage'. Does 'uncollectable' here means that these objects will never
> be collected?


No, but it does mean it's very likely they'll never be collected --
unless you do something to make them collectable.

> Why is that?


The gc module is documented in the Library Reference Manual. The docs
for gc.garbage there should answer all your questions here.

> They're not bound by anything once foo() exits.


> How can I make sure the memory allocated for this junk is deleted
> (since I want to run foo() in a loop).


Read the gc.garbage docs. Then don't create cycles containing objects
with __del__ methods, or, if you think you must, do what the docs say
to do <wink>.
 
Reply With Quote
 
Mel Wilson
Guest
Posts: n/a
 
      07-23-2004
In article <410044cb$(E-Mail Removed)>, Steve <(E-Mail Removed)> wrote:
>I saw an article online
>(http://aspn.activestate.com/ASPN/Coo...n/Recipe/65333) where it
>explains how one can find out if there's a memory leak in ones program.
>How is there a memory leak in this:
>
> # make a leak
> l = []

1 reference to the new list, in the namespace
under 'l'. Reference count == 1

> l.append(l)

1 more reference to the list, in its own
[0] element. Reference count == 2
> del l

The reference in the namespace is removed.
Reference count = 1

>??? Shouldn't deleting an object explicitly give the GC a better chance
>to find the object? Won't deleting it cause it's reference to go down
>(another question: which GC is python 2.3 using? Refcount or
>Generational?). Isn't 'del' similar to 'free'ing in C??


Not really. `del` removes a reference, which usually
culminates in freeing the storage, after all the required
dels are done.

For no memory leak:

l = [] # ref count = 1, i.e. l
l.append (l) # ref count = 2, i.e. l and :itself:[0]
m = l # ref count = 3, i.e. l, :itself:[0] and m
del l # ref count = 2, i.e. :itself:[0] and m
del m[0] # ref count = 1, i.e. m
del m # ref count = 0, and the objects space can be collected

(Here :itself: is made-up language, no way a valid Python
identifier, but how else to discuss a reference that isn't
part of any namespace?)

Regards. Mel.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
init of class members : mem(0) vs. mem() vs. not-init at all news.aon.at C++ 11 01-29-2011 07:30 PM
why does Sun JVM have a hard max mem limit of 93meg on 2gig pc with no setting modified? Mistton Java 2 04-19-2007 10:33 PM
allocating mem in a function and assigning a ptr to the first byte of that mem array... mast2as@yahoo.com C Programming 8 03-01-2007 08:18 AM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM



Advertisments