From: David G. <dav...@gm...> - 2006-08-17 23:25:18
|
Hello all, I had a massive memory leak in some of my code. It would basically end up using up all 1GB of my RAM or more if I don't kill the application. I managed to finally figure out which portion of the code was causing the leak (with great difficulty) and have a little example which exposes the leak. I am using numpy-0.9.8 and I'm wondering if perhaps this is already fixed in 1.0b2. Run this through valgrind with appropriate options (I used the recommended valgrind_py.sh that I found on scipy's site somewhere) and this will leak 100kB. Increase the xrange on the big loop and you can watch the memory increase over time in top. The interesting thing is that the only difference between the leaky and non-leaky code is: if not adjacencyMatrix[anInt2,anInt1] == 0: (leaky) vs. if not adjacencyMatrix[anInt2][anInt1] == 0: (non-leaky) however another way to make the leaky code non-leaky is to change anArrayOfInts to just be [1] Here's the code: from numpy import array def leakyCode(aListOfArrays, anArrayOfInts, adjacencyMatrix): ys = set() for aList in aListOfArrays: for anInt1 in anArrayOfInts: for anInt2 in aList: if not adjacencyMatrix[anInt2,anInt1] == 0: ys.add(anInt1) return ys def nonLeakyCode(aListOfArrays, anArrayOfInts, adjacencyMatrix): ys = set() for aList in aListOfArrays: for anInt1 in anArrayOfInts: for anInt2 in aList: if not adjacencyMatrix[anInt2][anInt1] == 0: ys.add(anInt1) return ys if __name__ == "__main__": for i in xrange(10000): aListOfArrays = [[0, 1]] anArrayOfInts = array([1]) adjacencyMatrix = array([[0,1],[1,0]]) #COMMENT OUT ONE OF THE 2 LINES BELOW #bar = nonLeakyCode(aListOfArrays, anArrayOfInts, adjacencyMatrix) bar = leakyCode(aListOfArrays, anArrayOfInts, adjacencyMatrix) -- David Grant http://www.davidgrant.ca |
From: Robert K. <rob...@gm...> - 2006-08-17 23:30:44
|
David Grant wrote: > Hello all, > > I had a massive memory leak in some of my code. It would basically end > up using up all 1GB of my RAM or more if I don't kill the application. I > managed to finally figure out which portion of the code was causing the > leak (with great difficulty) and have a little example which exposes the > leak. I am using numpy-0.9.8 and I'm wondering if perhaps this is > already fixed in 1.0b2. Run this through valgrind with appropriate > options (I used the recommended valgrind_py.sh that I found on scipy's > site somewhere) and this will leak 100kB. Increase the xrange on the big > loop and you can watch the memory increase over time in top. I don't see a leak in 1.0b2.dev3002. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco |
From: David G. <dav...@gm...> - 2006-08-18 00:08:33
|
On 8/17/06, Robert Kern <rob...@gm...> wrote: > > David Grant wrote: > > Hello all, > > > > I had a massive memory leak in some of my code. It would basically end > > up using up all 1GB of my RAM or more if I don't kill the application. I > > managed to finally figure out which portion of the code was causing the > > leak (with great difficulty) and have a little example which exposes the > > leak. I am using numpy-0.9.8 and I'm wondering if perhaps this is > > already fixed in 1.0b2. Run this through valgrind with appropriate > > options (I used the recommended valgrind_py.sh that I found on scipy's > > site somewhere) and this will leak 100kB. Increase the xrange on the big > > loop and you can watch the memory increase over time in top. > > I don't see a leak in 1.0b2.dev3002. Thanks Robert. I decided to upgrade to 1.0b2 just to see what I get and now I get 7kB of "possibly lost" memory, coming from PyObject_Malloc (in /usr/lib/libpython2.4.so.1.0). This is a constant 7kB, however, and it isn't getting any larger if I increase the loop iterations. Looks good then. I don't really know the meaning of this "possibly lost" memory. -- David Grant http://www.davidgrant.ca |
From: Albert S. <fu...@gm...> - 2006-08-18 10:31:10
|
Hello all > <snip> > I decided to upgrade to 1.0b2 just to see what I get and now I get 7kB of > "possibly lost" memory, coming from PyObject_Malloc (in > /usr/lib/libpython2.4.so.1.0). This is a constant 7kB, however, and it > isn't getting any larger if I increase the loop iterations. Looks good > then. I don't really know the meaning of this "possibly lost" memory. http://projects.scipy.org/scipy/numpy/ticket/195 This leak is caused by add_docstring, but it's supposed to leak. I wonder if there's a way to register some kind of on-exit handler in Python so that this can also be cleaned up? Cheers, Albert |
From: Fernando P. <fpe...@gm...> - 2006-08-18 23:53:02
|
> This leak is caused by add_docstring, but it's supposed to leak. I wonder if > there's a way to register some kind of on-exit handler in Python so that > this can also be cleaned up? import atexit atexit.register(your_cleanup_function) whose api is no args on input: def your_cleanup_function(): do_whatever... You could use here a little extension function which goes in and does the necessary free() calls on a pre-stored list of allocated pointers, if there's more than one (I don't really know what's going on here). Cheers, f |