Created attachment 106142 [details] Fix memory leaks and release allocated memory for some pointers clearly in FcFini. 1. The memory allocated for userconf, userdir and other_types is not released after FcFini was called. 2. The memory allocated for ot->object.object in Function _FcObjectLookupOtherTypeByName was not released before ot was released. The ot memory leak was fixed in the attachment. And two fini functions were added to FcFini so that we can free the memory clearly. My patch is just a quick workaround for these problems and I am not sure whether this patch breaks your infrastructure here. Test code for current mask branch: #include <stdio.h> #include <fontconfig/fontconfig.h> int main(int argc, char **argv) { FcInit(); printf("%d\n", FcGetVersion()); FcFini(); return 0; } valgrind output: $ valgrind --leak-check=full --show-leak-kinds=all ./test_fontconfig ==15109== Memcheck, a memory error detector ==15109== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==15109== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==15109== Command: ./test_fontconfig ==15109== ... 21101 ==15109== ==15109== HEAP SUMMARY: ==15109== in use at exit: 142 bytes in 6 blocks ==15109== total heap usage: 16,372 allocs, 16,366 frees, 11,725,333 bytes allocated ==15109== ==15109== 32 bytes in 2 blocks are still reachable in loss record 1 of 4 ==15109== at 0x4029E7C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==15109== by 0x404E8F3: _FcObjectLookupOtherTypeByName (fcobjs.c:61) ==15109== by 0x404EAA2: FcObjectLookupIdByName (fcobjs.c:101) ==15109== by 0x4056FAF: FcEndElement (fcxml.c:2576) ==15109== by 0x42E602D: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E7281: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E3FC0: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E5A31: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E8F8A: XML_ParseBuffer (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x4055948: FcConfigParseAndLoad (fcxml.c:3270) ==15109== by 0x4055C00: FcConfigParseAndLoad (fcxml.c:3129) ==15109== by 0x4055F46: FcEndElement (fcxml.c:2318) ==15109== ==15109== 34 bytes in 1 blocks are still reachable in loss record 2 of 4 ==15109== at 0x4029E7C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==15109== by 0x41D1420: strdup (strdup.c:43) ==15109== by 0x40572FE: FcEndElement (fcxml.c:2299) ==15109== by 0x42E602D: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E7281: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E3FC0: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E5A31: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E8F8A: XML_ParseBuffer (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x4055948: FcConfigParseAndLoad (fcxml.c:3270) ==15109== by 0x4055C00: FcConfigParseAndLoad (fcxml.c:3129) ==15109== by 0x4055F46: FcEndElement (fcxml.c:2318) ==15109== by 0x42E602D: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== ==15109== 38 bytes in 1 blocks are still reachable in loss record 3 of 4 ==15109== at 0x4029E7C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==15109== by 0x41D1420: strdup (strdup.c:43) ==15109== by 0x4057337: FcEndElement (fcxml.c:2305) ==15109== by 0x42E602D: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E7281: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E3FC0: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E5A31: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E8F8A: XML_ParseBuffer (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x4055948: FcConfigParseAndLoad (fcxml.c:3270) ==15109== by 0x4055C00: FcConfigParseAndLoad (fcxml.c:3129) ==15109== by 0x4055F46: FcEndElement (fcxml.c:2318) ==15109== by 0x42E602D: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== ==15109== 38 bytes in 2 blocks are still reachable in loss record 4 of 4 ==15109== at 0x4029E7C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==15109== by 0x41D1420: strdup (strdup.c:43) ==15109== by 0x404E907: _FcObjectLookupOtherTypeByName (fcobjs.c:65) ==15109== by 0x404EAA2: FcObjectLookupIdByName (fcobjs.c:101) ==15109== by 0x4056FAF: FcEndElement (fcxml.c:2576) ==15109== by 0x42E602D: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E7281: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E3FC0: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E5A31: ??? (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x42E8F8A: XML_ParseBuffer (in /usr/lib/libexpat.so.1.6.0) ==15109== by 0x4055948: FcConfigParseAndLoad (fcxml.c:3270) ==15109== by 0x4055C00: FcConfigParseAndLoad (fcxml.c:3129) ==15109== ==15109== LEAK SUMMARY: ==15109== definitely lost: 0 bytes in 0 blocks ==15109== indirectly lost: 0 bytes in 0 blocks ==15109== possibly lost: 0 bytes in 0 blocks ==15109== still reachable: 142 bytes in 6 blocks ==15109== suppressed: 0 bytes in 0 blocks ==15109== ==15109== For counts of detected and suppressed errors, rerun with: -v ==15109== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Thank you for the patch. however that looks not MT-safe to me. plus, next_id in fcobjs.c should be reset.
Created attachment 106863 [details] [review] MT-safe version The new patch is the MT-safe version of the first workaround. And next_id is protected by lock and also updated in FcObjectOtherTypeFini. It seemed that there are still other non MT-safe codes. These other codes are not part of this bug and aren't changed in this patch.
There's no need for MT-safety during shutdown.
simplified patch and fix a crash after re-entering FcInit() after FcFini() as well. Thanks.
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.