[PD-dev] PD Mem leaks WAS crash (memory leak?) with zexy?

[B. Bogart]

Hello all,

After more digging it appears that zexy is not causing a leak, but was
just the last process to request memory.

After using valgrind for some time it appears there are leaks all over
the place. The reason I'm having trouble narrowing things down is simply
that there are leaks in many different places.

I've attached the full valgrind log, but here are some high(low?)lights:

I was worried about my own gphoto code (not very well tested) which
seems to loose about 41,968 bytes. This makes the following numbers much
more worrisome:

==24879== 262,140 bytes in 1 blocks are definitely lost in loss record
220 of 229
==24879==    at 0x47F2D6E: malloc (vg_replace_malloc.c:207)
==24879==    by 0xADB5A06: (within /usr/lib/libGL.so.173.14.09)

==24879== 2,142,184 (2,134,057 direct, 8,127 indirect) bytes in 956
blocks are definitely lost in loss record 225 of 229
==24879==    at 0x47F0E22: calloc (vg_replace_malloc.c:397)
==24879==    by 0x80AD86D: getbytes (m_memory.c:24)
==24879==    by 0xA7D6FFF: gemwin::createMess(_symbol*) (gemwin.cpp:141)
==24879==    by 0xA7D70A6: gemwin::createMessCallback(void*, _symbol*)
(gemwin.cpp:702)
==24879==    by 0x80AA352: pd_typedmess (m_class.c:730)

==24879== 12,288,190 bytes in 10 blocks are definitely lost in loss
record 228 of 229
==24879==    at 0x47F2D6E: malloc (vg_replace_malloc.c:207)
==24879==    by 0x4D2EAA1: flext_root_single::operator new(unsigned) (in
/usr/lib/pd/extra/py.pd_linux)
==24879==    by 0x4D2F2DC: operator new[](unsigned) (in
/usr/lib/pd/extra/py.pd_linux)
==24879==    by 0xA7CA4A0: imageStruct::allocate(unsigned)
(GemPixUtil.cpp:129)
==24879==    by 0xA7C6D24: jpegImage2mem(char const*)
(GemPixImageLoad.cpp:560)
==24879==    by 0xA7C7999: image2mem(char const*) (GemPixImageLoad.cpp:192)
==24879==    by 0xA8343F0: pix_buffer::openMess(_symbol*, int)
(pix_buffer.cpp:201)
==24879==    by 0xA833D74: pix_buffer::openMessCallback(void*, _symbol*,
float) (pix_buffer.cpp:345)
==24879==    by 0x80AA352: pd_typedmess (m_class.c:730)

==24879== 2,286,470,533 bytes in 1,849 blocks are possibly lost in loss
record 229 of 229
==24879==    at 0x47F2D6E: malloc (vg_replace_malloc.c:207)
==24879==    by 0x4D2EAA1: flext_root_single::operator new(unsigned) (in
/usr/lib/pd/extra/py.pd_linux)
==24879==    by 0x4D2F2DC: operator new[](unsigned) (in
/usr/lib/pd/extra/py.pd_linux)
==24879==    by 0xA7CA4A0: imageStruct::allocate(unsigned)
(GemPixUtil.cpp:129)
==24879==    by 0xA7C6D24: jpegImage2mem(char const*)
(GemPixImageLoad.cpp:560)
==24879==    by 0xA7C7999: image2mem(char const*) (GemPixImageLoad.cpp:192)
==24879==    by 0xA862149: pix_image::openThread(void*) (pix_image.cpp:167)
==24879==    by 0x48464BF: start_thread (in
/lib/i686/cmov/libpthread-2.7.so)
==24879==    by 0x4C8C6DD: clone (in /lib/i686/cmov/libc-2.7.so)

I'm cross-posting to gem-dev since a few of these big ticket leaks
appear to be in Gem.

I'm currently testing with pd-0.39-2 (as I was able to use this in a
previous installation without any noticeable leakage). I also tried
pd-0.40-3 and pd-0.42-4.

I'm currently using r 2750 of Gem from SVN. I also tried the current
version of Gem from SVN, but that did not appear to solve the issue.

Any any of these definite, or possible leaks known and I'm just missing
the fix?

Any recommendations on how I can minimize the effect of these leaks?

All this has made me think perhaps an installation version of PD+crucial
externals would be useful, that is one that is tested for extremely long
periods and does not change very often.

Any advice appreciated.

Thanks,
B. Bogart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrind.log
Type: text/x-log
Size: 200974 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20090424/1a118319/attachment.bin>