However, I couldn't see how the leak was my fault really. So I ran Juce demo through valgrind too, with much the same result.
I am however still unsure how to read the results.
Some entries like this one:
- Code: Select all
==2727== 112 (8 direct, 104 indirect) bytes in 1 blocks are definitely lost in loss record 14 of 26
==2727== at 0x401C487: realloc (vg_replace_malloc.c:306)
==2727== by 0x40FE4D3: (within /usr/lib/libX11.so.6.2.0)
==2727== by 0x40FEF3B: (within /usr/lib/libX11.so.6.2.0)
==2727== by 0x4100C97: _XlcCreateLC (in /usr/lib/libX11.so.6.2.0)
==2727== by 0x411EEAA: _XlcDefaultLoader (in /usr/lib/libX11.so.6.2.0)
==2727== by 0x41077AE: _XOpenLC (in /usr/lib/libX11.so.6.2.0)
==2727== by 0x410789D: _XrmInitParseInfo (in /usr/lib/libX11.so.6.2.0)
==2727== by 0x40F14C0: (within /usr/lib/libX11.so.6.2.0)
==2727== by 0x40F2FE7: XrmGetStringDatabase (in /usr/lib/libX11.so.6.2.0)
==2727== by 0x40CC863: XGetDefault (in /usr/lib/libX11.so.6.2.0)
==2727== by 0x49E337C: _XcursorGetDisplayInfo (in /usr/lib/libXcursor.so.1.0.2)
==2727== by 0x49E35FC: XcursorSupportsARGB (in /usr/lib/libXcursor.so.1.0.2)
Points pretty clearly to xlib being the culprit.
But this one?
- Code: Select all
==2727== 72 bytes in 1 blocks are possibly lost in loss record 9 of 26
==2727== at 0x401B6CA: calloc (vg_replace_malloc.c:279)
==2727== by 0x400E188: (within /lib/ld-2.3.6.so)
==2727== by 0x400E24B: _dl_allocate_tls (in /lib/ld-2.3.6.so)
==2727== by 0x409781F: pthread_create@@GLIBC_2.1 (in /lib/tls/i686/cmov/libpthread-2.3.6.so)
==2727== by 0x814E85D: (within /Projects/juce/extras/juce demo/build/linux/build/jucedemo)
==2727== by 0x807BE5D: (within /Projects/juce/extras/juce demo/build/linux/build/jucedemo)
==2727== by 0x807BFD1: (within /Projects/juce/extras/juce demo/build/linux/build/jucedemo)
==2727== by 0x8095359: (within /Projects/juce/extras/juce demo/build/linux/build/jucedemo)
==2727== by 0x80966CE: (within /Projects/juce/extras/juce demo/build/linux/build/jucedemo)
==2727== by 0x814C0A9: (within /Projects/juce/extras/juce demo/build/linux/build/jucedemo)
==2727== by 0x8096544: (within /Projects/juce/extras/juce demo/build/linux/build/jucedemo)
==2727== by 0x8096623: (within /Projects/juce/extras/juce demo/build/linux/build/jucedemo)
(If you make a debug build with symbols you get line numbers, but I didn't)
I guess what I'm asking is in which direction one should parse this call stack. Is the likely offender at the top or the bottom?
The leaks are not tremendous in either case, but it's strange that asound and xlib are not better checked. They show up all over the place.

