Bug 17661

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.