[SciPy-user] Memory leak in delaunay interpolator
Michael.Abshoff
michael.abshoff@googlemail....
Wed Jan 16 23:06:42 CST 2008
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@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
More information about the SciPy-user
mailing list