[SciPy-user] Memory leak in delaunay interpolator

[Michael.Abshoff]

Pauli Virtanen wrote:
> Wed, 16 Jan 2008 20:40:33 +0100, Nils Wagner wrote:
> 
>> On Wed, 16 Jan 2008 11:38:02 +0100
>>   Rob Hetland <hetland at tamu.edu> wrote:
>>> I'm not sure who else uses the delaunay package (was in
>>>
>>> scipy.sandbox, now lives in scikits), but I find it
>>> indispensable. Today I found what appears to be a memory leak in the
>>> interpolator and extrapolator objects.  This simple code demonstrates
>>> the leak:
> 
> This may be the same as bug #382 (patch is available in the ticket).
> 
> Also #376 may be relevant for the observed segfault: there are
> (or were?) known crasher bugs in the delaunay module.
> 

Hi,

I ran the following code in Sage under valgrind's memcheck [slightly 
adapted from the previous post]:

sage: from delaunay import *
sage: from numpy.random import rand
sage: xi, yi = rand(2, 1000)
sage: tri=Triangulation(xi, yi)
sage: for n in range(100000):
....:         interp = tri.nn_interpolator(rand(1000))
....:     z = interp(x, y)

using today's scipy sandbox checkout. The following popped up:

==16816== 6,944 bytes in 1 blocks are definitely lost in loss record 
7,840 of 8,087
==16816==    at 0x4A1BB35: malloc (vg_replace_malloc.c:207)
==16816==    by 0x1BFE7829: VoronoiDiagramGenerator::myalloc(unsigned) 
(VoronoiDiagramGenerator.cpp:725)
==16816==    by 0x1BFE788D: VoronoiDiagramGenerator::PQinitialize() 
(VoronoiDiagramGenerator.cpp:570)
==16816==    by 0x1BFE8305: VoronoiDiagramGenerator::voronoi(int) 
(VoronoiDiagramGenerator.cpp:924)
==16816==    by 0x1BFE89DA: 
VoronoiDiagramGenerator::generateVoronoi(double*, double*, int, double, 
double, double, double,
double) (VoronoiDiagramGenerator.cpp:136)
==16816==    by 0x1BFE65D7: delaunay_method (_delaunay.cpp:125)
==16816==    by 0x4833C1: PyEval_EvalFrameEx (ceval.c:3564)
==16816==    by 0x4852CA: PyEval_EvalCodeEx (ceval.c:2831)
==16816==    by 0x4CE817: function_call (funcobject.c:517)
==16816==    by 0x415542: PyObject_Call (abstract.c:1860)
==16816==    by 0x41BC62: instancemethod_call (classobject.c:2497)
==16816==    by 0x415542: PyObject_Call (abstract.c:1860)

I am not sure if the patch from #382 has been applied to svn trunk, I am 
still finding my way around scipy.

The other oddity that popped up was:

==16816==    at 0x15A89C1D: PyArray_MapIterReset (arrayobject.c:9854)
==16816==    by 0x15AC4827: array_subscript (arrayobject.c:2403)
==16816==    by 0x15AC4B54: array_subscript_nice (arrayobject.c:3030)
==16816==    by 0x47FA38: PyEval_EvalFrameEx (ceval.c:1192)
==16816==    by 0x4843CA: PyEval_EvalFrameEx (ceval.c:3650)
==16816==    by 0x4852CA: PyEval_EvalCodeEx (ceval.c:2831)
==16816==    by 0x4CE817: function_call (funcobject.c:517)
==16816==    by 0x415542: PyObject_Call (abstract.c:1860)
==16816==    by 0x41BC62: instancemethod_call (classobject.c:2497)
==16816==    by 0x415542: PyObject_Call (abstract.c:1860)
==16816==    by 0x455F97: slot_tp_init (typeobject.c:4862)
==16816==    by 0x458E40: type_call (typeobject.c:436)

If you are interested [and aren't already doing it] I could run valgrind 
on the whole numpy/scipy test suite on a regular basis. I already do 
that on a weekly basis for the Sage doctests, so adding it wouldn't be 
too much work once I have the build and testing automated.

Cheers,

Michael