Thread: How to fix memory leak possibly caused by libfontconfig.so? -- implied by valgrind

  1. #1
    Registered User
    Join Date
    Nov 2007
    Posts
    33

    How to fix memory leak possibly caused by libfontconfig.so? -- implied by valgrind

    I've write a program that acts abnormally, e.g., if I resize three vectors subsequently, the second resize will alter the size of the first...

    So I guess there might be some memory leak or improper address writing, however, after running valgrind I have the following output.

    It suggest that it may caused by libfontconfig.so, but how can I fix problems caused by library?

    Or maybe it's just a false positive from valgrind?

    Thanks in advance!

    ================================================== =========

    valgrind output:

    ==7444== Memcheck, a memory error detector.
    ==7444== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
    ==7444== Using LibVEX rev 1658, a library for dynamic binary translation.
    ==7444== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
    ==7444== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
    ==7444== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
    ==7444== For more details, rerun with: -v
    ==7444==
    ==7444==
    ==7444== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 63 from 1)
    ==7444== malloc/free: in use at exit: 1,202,797 bytes in 2,907 blocks.
    ==7444== malloc/free: 17,665 allocs, 14,758 frees, 27,516,494 bytes allocated.
    ==7444== For counts of detected errors, rerun with: -v
    ==7444== searching for pointers to 2,907 not-freed blocks.
    ==7444== checked 1,963,956 bytes.
    ==7444==
    ==7444== 38 bytes in 2 blocks are definitely lost in loss record 37 of 122
    ==7444== at 0x4021620: malloc (vg_replace_malloc.c:149)
    ==7444== by 0x46B3837: FcStrCopy (in /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46B6D6C: (within /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x474D3E5: (within /usr/lib/libexpat.so.1.0.0)
    ==7444== by 0x474E06C: (within /usr/lib/libexpat.so.1.0.0)
    ==7444== by 0x474F06D: (within /usr/lib/libexpat.so.1.0.0)
    ==7444== by 0x474FFB4: (within /usr/lib/libexpat.so.1.0.0)
    ==7444== by 0x474779A: XML_ParseBuffer (in /usr/lib/libexpat.so.1.0.0)
    ==7444== by 0x46B5E8B: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46B6185: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46B6287: (within /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46B66F1: (within /usr/lib/libfontconfig.so.1.2.0)
    ==7444==
    ==7444==
    ==7444== 544 (384 direct, 160 indirect) bytes in 3 blocks are definitely lost in loss record 82 of 122
    ==7444== at 0x4021620: malloc (vg_replace_malloc.c:149)
    ==7444== by 0x46B1313: (within /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46B1C06: (within /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46B1D07: (within /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46B6C50: (within /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x474D3E5: (within /usr/lib/libexpat.so.1.0.0)
    ==7444== by 0x474E06C: (within /usr/lib/libexpat.so.1.0.0)
    ==7444== by 0x474F06D: (within /usr/lib/libexpat.so.1.0.0)
    ==7444== by 0x474FFB4: (within /usr/lib/libexpat.so.1.0.0)
    ==7444== by 0x474779A: XML_ParseBuffer (in /usr/lib/libexpat.so.1.0.0)
    ==7444== by 0x46B5E8B: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46B6185: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
    ==7444==
    ==7444==
    ==7444== 1,072 (384 direct, 688 indirect) bytes in 1 blocks are definitely lost in loss record 92 of 122
    ==7444== at 0x402171B: realloc (vg_replace_malloc.c:306)
    ==7444== by 0x46B1253: (within /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46B1C06: (within /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46B20FB: (within /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46AE9BF: FcFontRenderPrepare (in /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46AEBA7: FcFontSetMatch (in /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x46AED59: FcFontMatch (in /usr/lib/libfontconfig.so.1.2.0)
    ==7444== by 0x43F3A2F: XftFontMatch (in /usr/lib/libXft.so.2.1.2)
    ==7444== by 0x43F3D70: XftFontOpen (in /usr/lib/libXft.so.2.1.2)
    ==7444== by 0x40BA4F0: (within /usr/lib/libfltk.so.1.1)
    ==7444== by 0x40BA57D: Fl_FontSize::Fl_FontSize(char const*) (in /usr/lib/libfltk.so.1.1)
    ==7444== by 0x40BA67B: fl_font(int, int) (in /usr/lib/libfltk.so.1.1)
    ==7444==
    ==7444== LEAK SUMMARY:
    ==7444== definitely lost: 806 bytes in 6 blocks.
    ==7444== indirectly lost: 848 bytes in 42 blocks.
    ==7444== possibly lost: 0 bytes in 0 blocks.
    ==7444== still reachable: 1,201,143 bytes in 2,859 blocks.
    ==7444== suppressed: 0 bytes in 0 blocks.
    ==7444== Reachable blocks (those to which a pointer was found) are not shown.
    ==7444== To see them, rerun with: --show-reachable=yes

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    It's (probably) an incorrect result from valgrind.

    From what you say, the problem is in your own code (eg dereferencing a dangling pointer, etc). The problem with such things is that the impact of such actions are highly variable (eg two possible effects are corrupting one of your data structures, or overwriting data used by a library that is being used implicitly by your program). valgrind (or any similar tool) typically detects symptoms of problems, but the relationship between the symptom and the cause is not always obvious.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Getting an error with OpenGL: collect2: ld returned 1 exit status
    By Lorgon Jortle in forum C++ Programming
    Replies: 6
    Last Post: 05-08-2009, 08:18 PM
  2. Pointer's
    By xlordt in forum C Programming
    Replies: 13
    Last Post: 10-14-2003, 02:15 PM
  3. Memory Leak?
    By BigDaddyDrew in forum C++ Programming
    Replies: 11
    Last Post: 12-09-2002, 04:28 PM
  4. Manipulating the Windows Clipboard
    By Johno in forum Windows Programming
    Replies: 2
    Last Post: 10-01-2002, 09:37 AM
  5. Is it necessary to write a specific memory manager ?
    By Morglum in forum Game Programming
    Replies: 18
    Last Post: 07-01-2002, 01:41 PM