jutirain

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

grumpy

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.