Closed
Description
First, the relevant output of valgrind with --tool=memcheck --leak-check=full --show-leak-kinds=all:
==2657== 4,841,396 bytes in 2 blocks are still reachable in loss record 4,337 of 4,341
==2657== at 0x4C2BC79: operator new[](unsigned long) (vg_replace_malloc.c:384)
==2657== by 0x2D592353: RendererAgg::tostring_rgba_minimized(Py::Tuple const&) (_backend_agg.cpp:2382)
==2657== by 0x2D5A3363: Py::PythonExtension<RendererAgg>::method_varargs_call_handler(_object*, _object*) (ExtensionOldType.hxx:291)
==2657== by 0x54BB13: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x54C027: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x54C027: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x54C027: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x577BE1: ??? (in /usr/bin/python2.7)
==2657==
==2657== 55,424,972 bytes in 33 blocks are definitely lost in loss record 4,339 of 4,341
==2657== at 0x4C2BC79: operator new[](unsigned long) (vg_replace_malloc.c:384)
==2657== by 0x2D592353: RendererAgg::tostring_rgba_minimized(Py::Tuple const&) (_backend_agg.cpp:2382)
==2657== by 0x2D5A3363: Py::PythonExtension<RendererAgg>::method_varargs_call_handler(_object*, _object*) (ExtensionOldType.hxx:291)
==2657== by 0x54BB13: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x54C027: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x54C027: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x54C027: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x577BE1: ??? (in /usr/bin/python2.7)
==2657==
==2657== 56,230,256 bytes in 25 blocks are possibly lost in loss record 4,340 of 4,341
==2657== at 0x4C2BC79: operator new[](unsigned long) (vg_replace_malloc.c:384)
==2657== by 0x2D592353: RendererAgg::tostring_rgba_minimized(Py::Tuple const&) (_backend_agg.cpp:2382)
==2657== by 0x2D5A3363: Py::PythonExtension<RendererAgg>::method_varargs_call_handler(_object*, _object*) (ExtensionOldType.hxx:291)
==2657== by 0x54BB13: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x54C027: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x54C027: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x54C027: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==2657== by 0x575D91: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==2657== by 0x577BE1: ??? (in /usr/bin/python2.7)
==2657==
==2657== LEAK SUMMARY:
==2657== definitely lost: 55,490,524 bytes in 83 blocks
==2657== indirectly lost: 20,256 bytes in 407 blocks
==2657== possibly lost: 56,383,520 bytes in 481 blocks
==2657== still reachable: 11,403,937 bytes in 13,860 blocks
==2657== suppressed: 179,227,068 bytes in 27,533 blocks
I am drawing many maps (with basemap) with polygon collections using the agg backend and then save them as png or svg. I always close the figures and start fresh. The more I draw the higher the memory usage gets, which is why I ran memcheck. I will try to come up with a minimal example that reproduces this.
I am using mpl 1.3.1, basemap 1.0.7, Python 2.7.3.
Metadata
Metadata
Assignees
Labels
No labels