Tracking down memory leaks?

[MKoool]

I have an application with one function called "compute", which given a
filename, goes through that file and performs various statistical
analyses. It uses arrays extensively and loops alot. it prints the
results of it's statistical significance tests to standard out. Since
the compute function returns and I think no variables of global scope
are being used, I would think that when it does, all memory returns
back to the operating system.

Instead, what I see is that every iteration uses several megs more.
For example, python uses 52 megs when starting out, it goes through
several iterations and I'm suddenly using more than 500 megs of ram.

Does anyone have any pointers on how to figure out what I'm doing
wrong?

Thanks,
mohan

[Felipe Almeida Lessa]

Em Dom, 2006-02-12 Ã*s 05:11 -0800, MKoool escreveu:

I have an application with one function called "compute", which given a
filename, goes through that file and performs various statistical
analyses. It uses arrays extensively and loops alot. it prints the
results of it's statistical significance tests to standard out. Since
the compute function returns and I think no variables of global scope
are being used, I would think that when it does, all memory returns
back to the operating system.

Instead, what I see is that every iteration uses several megs more.
For example, python uses 52 megs when starting out, it goes through
several iterations and I'm suddenly using more than 500 megs of ram.

Does anyone have any pointers on how to figure out what I'm doing
wrong?
Have you tried to force a garbage collection? Try, for example, running
gc.collect() everytime the function returns. See
http://www.python.org/doc/current/lib/module-gc.html for more details.
Thanks,
mohan

Cya,
Felipe.

--
"Quem excele em empregar a força militar subjulga os exércitos dos
outros povos sem travar batalha, toma cidades fortificadas dos outros
povos sem as atacar e destrói os estados dos outros povos sem lutas
prolongadas. Deve lutar sob o Céu com o propósito primordial da
'preservação' . Desse modo suas armas não se embotarão, e os ganhos
poderão ser preservados. Essa é a estratégia para planejar ofensivas."

-- Sun Tzu, em "A arte da guerra"

[dmsbox2000-list1]

I *think* Python uses reference counting for garbage collection. I've
heard talk of people wanting to change this (to mark and sweep?).
Anyway, Python stores a counter with each object. Everytime you make a
reference to an object this counter is increased. Everytime a pointer
to the object is deleteted or reassigned the counter is decreased.
When the counter reaches zero the object is freed from memory. A flaw
with this algorithm is that if you create a circular reference the
object will never be freed. A linked list where the tail points to the
head will have a reference count of 1 for each node, after the head
pointer is deleted. So the list is never freed. Make sure you are not
creating a circular reference. Something like this:

a = [1, 2, 3, 4, 5, 6]
b = ['a', 'b', 'c', 'd']
c = [10, 20, 30, 40]

a[3] = b
b[1] = c
c[0] = a

the last assignment creates a circular refence, and until it is
removed, non of these objects will be removed from memory.

I'm not an expert on python internals, and it is possible that they
have a way of checking for cases like this. I think the deepcopy
method catches this, but I don't *think* basic garbage collection look
for this sort of thing.

David

[Steven D'Aprano]

On Sun, 12 Feb 2006 05:11:02 -0800, MKoool wrote:

I have an application with one function called "compute", which given a
filename, goes through that file and performs various statistical
analyses. It uses arrays extensively and loops alot. it prints the
results of it's statistical significance tests to standard out. Since
the compute function returns and I think no variables of global scope
are being used, I would think that when it does, all memory returns
back to the operating system.
I may be mistaken, and if so I will welcome the correction, but Python
does not return memory to the operating system until it terminates.

Objects return memory to Python when they are garbage collected, but not
the OS.

Instead, what I see is that every iteration uses several megs more.
For example, python uses 52 megs when starting out, it goes through
several iterations and I'm suddenly using more than 500 megs of ram.

Does anyone have any pointers on how to figure out what I'm doing
wrong?

How big is the file you are reading in? If it is (say) 400 MB, then it is
hardly surprising that you will be using 500MB of RAM. If the file is 25K,
that's another story.

How are you storing your data while you are processing it? I'd be looking
for hidden duplicates.

I suggest you re-factor your program. Instead of one giant function, break
it up into lots of smaller ones, and call them from compute. Yes, this
will use a little more memory, which might sound counter-productive at the
moment when you are trying to use less memory, but in the long term it
will allow your computer to use memory more efficiently (it is easier to
page small functions as they are needed than one giant function), and it
will be much easier for you to write and debug when you can isolate
individual pieces of the task in individual functions.

Re-factoring will have another advantage: you might just find the problem
on your own.
--
Steven.

[Fredrik Lundh]

"dm************ **@yahoo.com" wrote:

I'm not an expert on python internals, and it is possible that they
have a way of checking for cases like this. I think the deepcopy
method catches this, but I don't *think* basic garbage collection look
for this sort of thing.

http://www.python.org/doc/faq/genera...-manage-memory

</F>

[mensanator]

MKoool wrote:

I have an application with one function called "compute", which given a
filename, goes through that file and performs various statistical
analyses. It uses arrays extensively and loops alot. it prints the
results of it's statistical significance tests to standard out. Since
the compute function returns and I think no variables of global scope
are being used, I would think that when it does, all memory returns
back to the operating system.

Instead, what I see is that every iteration uses several megs more.
For example, python uses 52 megs when starting out, it goes through
several iterations and I'm suddenly using more than 500 megs of ram.

Does anyone have any pointers on how to figure out what I'm doing
wrong?
Are you importing any third party modules? It's not unheard of that
someone else's code has a memory leak.

Thanks,
mohan

[Steven D'Aprano]

On Sun, 12 Feb 2006 06:01:55 -0800, dm************* *@yahoo.com wrote:

I *think* Python uses reference counting for garbage collection.
Yes it does, with special code for detecting and collecting circular
references.
I've
heard talk of people wanting to change this (to mark and sweep?).
Reference counting is too simple to be cool *wink*

[snip] Make sure you are not creating
a circular reference. Something like this:

a = [1, 2, 3, 4, 5, 6]
b = ['a', 'b', 'c', 'd']
c = [10, 20, 30, 40]

a[3] = b
b[1] = c
c[0] = a

the last assignment creates a circular refence, and until it is removed,
non of these objects will be removed from memory.
I believe Python now handles this sort of situation very well now.

I'm not an expert on python internals, and it is possible that they have
a way of checking for cases like this. I think the deepcopy method
catches this, but I don't *think* basic garbage collection look for this
sort of thing.

deepcopy has nothing to do with garbage collection.

This is where you use deepcopy:

py> a = [2, 4, [0, 1, 2], 8] # note the nested list
py> b = a # b and a both are bound to the same list
py> b is a # b is the same list as a, not just a copy
True
py> c = a[:] # make a shallow copy of a
py> c is a # c is a copy of a, not a itself
False
py> c[2] is a[2] # but both a and c include the same nested list
True

What if you want c to include a copy of the nested list? That's where you
use deepcopy:

py> d = copy.deepcopy(a )
py> d[2] is a[2]
False

--
Steven.

[gene tani]

me********@aol. com wrote:

MKoool wrote:

I have an application with one function called "compute", which given a
filename, goes through that file and performs various statistical
analyses. It uses arrays extensively and loops alot. it prints the
results of it's statistical significance tests to standard out. Since
the compute function returns and I think no variables of global scope
are being used, I would think that when it does, all memory returns
back to the operating system.

Instead, what I see is that every iteration uses several megs more.
For example, python uses 52 megs when starting out, it goes through
several iterations and I'm suddenly using more than 500 megs of ram.

Does anyone have any pointers on how to figure out what I'm doing
wrong?

Are you importing any third party modules? It's not unheard of that
someone else's code has a memory leak.

- sounds like you're working with very large, very sparse matrices,
running LSI/SVD or a PCA/covariance analysis, something like that. So
it's a specialized problem, you need to specify what libs you're using,
what your platform / O/S is, py release, how you installed it, details
about C estensions, pyrex/psyco/swig, the more info you supply, the
mroe you get back.

- be aware there's wrong ways to measure memory, e.g. this long thread:
http://mail.python.org/pipermail/pyt...er/310121.html

[dmsbox2000-list1]

>> I'm not an expert on python internals, and it is possible that they have

a way of checking for cases like this. I think the deepcopy method
catches this, but I don't *think* basic garbage collection look for this
sort of thing.

deepcopy has nothing to do with garbage collection.

This is where you use deepcopy:

py> a = [2, 4, [0, 1, 2], 8] # note the nested list
py> b = a # b and a both are bound to the same list
py> b is a # b is the same list as a, not just a copy
True
py> c = a[:] # make a shallow copy of a
py> c is a # c is a copy of a, not a itself
False
py> c[2] is a[2] # but both a and c include the same nested list
True

What if you want c to include a copy of the nested list? That's where you
use deepcopy:

py> d = copy.deepcopy(a )
py> d[2] is a[2]
False

What I ment is that deepcopy is recursive, and if you have a circular
reference in your data structure a recursive copy will become infinite.
I think deepcopy has the ability to detect this situation. So if it
could be detected for deepcopy, I don't see why it could not be
detected for garbage collection purposes.

David

[malv]

Hi Steven,

Is there any way for making Python return memory no longer needed to
the OS? Cases may arise where you indeed need a big memory block
temporarily without being able to split it up into smaller chunks.
Thank you.
malv

Steven D'Aprano wrote:

Objects return memory to Python when they are garbage collected, but not
the OS.