Created attachment 19012 [details] [review] patch against 2.6.0 code of: #include <fontconfig/fontconfig.h> int main(void) { FcInit(); FcFini(); return 0; } valgrind --leak-check=full ./a.out output of... ==6729== 98 bytes in 6 blocks are definitely lost in loss record 1 of 1 ==6729== at 0x4A0739E: malloc (vg_replace_malloc.c:207) ==6729== by 0x353DE1A333: FcStrCopy (fcstr.c:42) ==6729== by 0x353DE1D874: FcEndElement (fcxml.c:1936) ==6729== by 0x353CA0AC22: (within /lib64/libexpat.so.1.5.2) ==6729== by 0x353CA0BB53: (within /lib64/libexpat.so.1.5.2) ==6729== by 0x353CA0CB55: (within /lib64/libexpat.so.1.5.2) ==6729== by 0x353CA0DDBA: (within /lib64/libexpat.so.1.5.2) ==6729== by 0x353CA03FA0: XML_ParseBuffer (in /lib64/libexpat.so.1.5.2) ==6729== by 0x353DE1BDA8: FcConfigParseAndLoad (fcxml.c:2552) ==6729== by 0x353DE1C08D: FcConfigParseAndLoad (fcxml.c:2438) ==6729== by 0x353DE1D4D4: FcEndElement (fcxml.c:1648) ==6729== by 0x353CA0AC22: (within /lib64/libexpat.so.1.5.2) looks like that in fcxml.c FcValues created in FcPopValue are not destroyed. And even when they are destroyed, then the test in fcpat.c to only allow a string to be destroyed if it is not hashed does a strcmp against the hashtable contents. So if a FcValue with a freshly malloced string, a copy of which also happens to exist in the hash, is destroyed, then its string is left to dangle as the hash test thinks that it is being asked to destroy the string belonging to the hash which happens to have the same contents.
In my tree: Created commit b5a7964: Don't leak FcValues string loaded through fcxml.c (#17661) 2 files changed, 7 insertions(+), 5 deletions(-)
I believe I've fixed this in 2.7.0. Please reopen otherwise.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.