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