Dear Marcel, deal all,

   I had a look to the root of the problem last time. I will see to it again.
Basically it is a problem in a inner loop when PyGSL is converting the arrays.
The last problem Ling Li posted, was only getting in trouble for arrays of length 0.
So I did not investigate it too much further as I was not aware that
arrays of length zero could be of practical interest.

When do you run into that trouble? Could you post a simple example?

Sincerely yours

-----Ursprüngliche Nachricht-----
Von: Marcel Tünnissen []
Gesendet: Sa 23.04.2011 07:42
Betreff: Re: [pygsl-discuss] Memory leak


I seem to have a similar problem as Ling Li but then with the
multiroots. Any news on this subject? Any workaround, like in the way
of handling the exception in my code? Or should I perhaps open an bug


Ling Li wore:

I found a memory leak when exception happens.  I was using pygsl 0.95
and gsl 1.13 on Fedora 12, but switching to gsl 1.14 (from Fedora
rawhide) gave the same memory leak problem.

Here's a test Python code (I am using blas.dtrmv as an example,
although the memory leak happens to many other functions I've tried):

from pygsl import blas
import numpy
import sys

def test_pygsl_memory_leak():
    n = 2000
    A = numpy.zeros([n, n], order='F')  # to trigger a sanity check in gsl
    b = numpy.zeros(n)
    print sys.getrefcount(A), sys.getrefcount(b)
        l = blas.dtrmv(A[:0, :0], b[:0])
    except Exception as e:
        print e
    print sys.getrefcount(A), sys.getrefcount(b)

And the output:

$ python
Python 2.6.2 (r262:71600, Jun  4 2010, 18:28:58)
[GCC 4.4.3 20100127 (Red Hat 4.4.3-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from memory import test_pygsl_memory_leak
>>> test_pygsl_memory_leak()
2 2
sanity check failed - shouldn't happen: Stride not one of a contiguous array!
3 3

If one runs it many many times in an interpreter, you will see the
memory usage goes up pretty quickly.