On Saturday, April 24, 2021 at 1:58:24 PM UTC-7 quantumno wrote:
they seem to be mostly re fonts
maybe i dont need some of these libs?
maybe there are alternatives?
i have tried updating libfontconfig and its a train wreck.
the following valgrind report is incomplete but typical:
416 (256 direct, 160 indirect) bytes in 1 blocks are definitely lost in loss record 412 of 563
??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
??? (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
??? (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
??? (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
??? (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
XftDefaultHasRender (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
XftDefaultSubstitute (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
XftFontMatch (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
Fl_Font_Descriptor::Fl_Font_Descriptor(char const*, int, int) (in /home/dave/progs/tylo/8/tylo)
fl_xft_font(Fl_Xlib_Graphics_Driver*, int, int, int) (in /home/dave/progs/tylo/8/tylo)
Fontconfig occasionally uses curious data structures, for example using offsets instead of pointers to access allocated memory. Valgrind gets confused.
Other system libraries have similar quirks, or allocate memory at startup that is only freed by the OS at exit, or whatever. Valgrind suppression files are your friend.
My valgrind suppression statement for fontconfig is:
{
libfontconfig_Supress
Memcheck:Leak
fun:*alloc
...
obj:/usr/lib64/libfontconfig.so.1.12.0
...
}
The first line is just an ID string. The other lines tell valgrind to ignore anything that happens in a function ending in 'alloc' in libfontconfig.so.1.12.0. The suppression file
usually has to be updated whenever the system libraries are updated.
Valgrind can help generate these suppression blocks if you run it with '--gen-suppressions=yes'. Then use '--suppressions=mysuppfile.supp' on your next valgrind run.
I like to edit the valgrind-generated suppressions to make them more general, eg, one '*alloc' line can block multiple alloc calls that valgrind finds problematical in a library.
The only caveat is that it's wise to first verify that it's not your program that is causing the memory leak, for example by calling the library API incorrectly. This is usually quite easy to do:
first, the library startup non-leaks are usually easily identified by the names at the bottom of the valgrind stack dump (ie if the leak started with a call to 'Init_Fontconfig()' it's
not likely anything you need to worry about), and second, use htop or some other monitor to verify your program isn't growing in size whenever it's doing something that
accesses the library API. Again, refer to the valgrind call stack to see where problems might exist before blindly adding suppressions to valgrind.
