Bug 83770 - Static pointers leaks
Summary: Static pointers leaks
Status: RESOLVED FIXED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.11
Hardware: All All
: medium major
Assignee: fontconfig-bugs
QA Contact: Behdad Esfahbod
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-11 15:47 UTC by Jia Wang
Modified: 2015-05-22 07:55 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Fix memory leaks and release allocated memory for some pointers clearly in FcFini. (2.65 KB, text/plain)
2014-09-11 15:47 UTC, Jia Wang
Details
MT-safe version (6.31 KB, patch)
2014-09-25 17:22 UTC, Jia Wang
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Jia Wang 2014-09-11 15:47:41 UTC
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)
Comment 1 Akira TAGOH 2014-09-25 02:58:58 UTC
Thank you for the patch. however that looks not MT-safe to me.
plus, next_id in fcobjs.c should be reset.
Comment 2 Jia Wang 2014-09-25 17:22:23 UTC
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.
Comment 3 Behdad Esfahbod 2014-10-15 03:08:41 UTC
There's no need for MT-safety during shutdown.
Comment 4 Akira TAGOH 2015-05-22 07:55:07 UTC
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.