Can anybody help me to explain why Valgrind reports th following memory leakage?

[jiapei100]

Hi, all:

I'm actually testing on one of my wxWidget application. I really hope
Valgrind will report "no memory leakage" for this application.
However, I obtained 6 leakage feedbacks as:


1)   It seems this item has nothing to do with my own program, all
related to gtk. Maybe, gtk is leaking some memories ?????
==18443==
==18443== 156 (36 direct, 120 indirect) bytes in 1 blocks are
definitely lost in loss record 59 of 189
==18443==    at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==18443==    by 0x544A548: (within /lib/tls/i686/cmov/libc-2.9.so)
==18443==    by 0x544AE25: __nss_database_lookup (in
/lib/tls/i686/cmov/libc-2.9.so)
==18443==    by 0x4044F5B: ???
==18443==    by 0x4045CBE: ???
==18443==    by 0x53F0811: getpwnam_r (in /lib/tls/i686/cmov/libc-2.9.so)
==18443==    by 0x5B83E71: g_get_any_init_do (gutils.c:1631)
==18443==    by 0x5B85924: g_get_home_dir (gutils.c:1782)
==18443==    by 0x564D467: gtk_rc_add_initial_default_files (gtkrc.c:557)
==18443==    by 0x565006A: _gtk_rc_init (gtkrc.c:896)
==18443==    by 0x56000B4: post_parse_hook (gtkmain.c:719)
==18443==    by 0x5B5DE04: g_option_context_parse (goption.c:1813)
==18443==
2) This seems to be wxWidget is leaking some memories.
==18443==
==18443== 70 bytes in 1 blocks are definitely lost in loss record 75 of 189
==18443==    at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==18443==    by 0x78F25BC: XRRGetOutputInfo (in /usr/lib/libXrandr.so.2.2.0)
==18443==    by 0x58D7BCC: init_multihead (gdkscreen-x11.c:733)
==18443==    by 0x58D82DE: _gdk_x11_screen_new (gdkscreen-x11.c:992)
==18443==    by 0x58BE133: gdk_display_open (gdkdisplay-x11.c:206)
==18443==    by 0x5896C44: gdk_display_open_default_libgtk_only (gdk.c:316)
==18443==    by 0x55FFDCE: gtk_init_check (gtkmain.c:957)
==18443==    by 0x44C3241: wxApp::Initialize(int&, wchar_t**) (in
/usr/lib/libwx_gtk2u_core-2.8.so.0.5.0)
==18443==    by 0x47B9B0B: wxEntryStart(int&, wchar_t**) (in
/usr/lib/libwx_baseu-2.8.so.0.5.0)
==18443==    by 0x47B9D6B: wxEntry(int&, wchar_t**) (in
/usr/lib/libwx_baseu-2.8.so.0.5.0)
==18443==    by 0x47B9FA6: wxEntry(int&, char**) (in
/usr/lib/libwx_baseu-2.8.so.0.5.0)
==18443==    by 0x80726C1: main (aambuildinggui.cpp:6)
==18443==
3) What is this?
==18443==
==18443== 148 (128 direct, 20 indirect) bytes in 1 blocks are
definitely lost in loss record 99 of 189
==18443==    at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==18443==    by 0x5AAC9D6: FcPatternObjectInsertElt (fcpat.c:367)
==18443==    by 0x5AAD3C7: FcPatternObjectAddWithBinding (fcpat.c:515)
==18443==    by 0x5AAD4DE: FcPatternAppend (fcpat.c:991)
==18443==    by 0x5AB2FBE: FcEndElement (fcxml.c:2023)
==18443==    by 0x5C7EEC3: (within /usr/lib/libexpat.so.1.5.2)
==18443==    by 0x5C7FC10: (within /usr/lib/libexpat.so.1.5.2)
==18443==    by 0x5C815EE: (within /usr/lib/libexpat.so.1.5.2)
==18443==    by 0x5C81CE6: (within /usr/lib/libexpat.so.1.5.2)
==18443==    by 0x5C7868B: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2)
==18443==    by 0x5AB0EFD: FcConfigParseAndLoad (fcxml.c:2552)
==18443==    by 0x5AB1245: FcConfigParseAndLoad (fcxml.c:2438)
==18443==
4) This must be happening in my code. However, I really can't see why
there is a bug in my own code... Is it possible that this memory
leakage has something to do with the event handle??
==18443==
==18443== 560 bytes in 2 blocks are definitely lost in loss record 130 of 189
==18443==    at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==18443==    by 0x48EE1FA: cv::fastMalloc(unsigned int) (cxalloc.cpp:62)
==18443==    by 0x48EE252: cvAlloc (cxalloc.cpp:688)
==18443==    by 0x48F22B4: cvCreateData (cxarray.cpp:867)
==18443==    by 0x48F2B2F: cvCreateMat (cxarray.cpp:94)
==18443==    by 0x80F3C0C: cvCalcSamplesMeanNSD(CvMat const*, CvMat*,
CvMat*) (cvcommon.h:279)
==18443==    by 0x80F4713:
VO_ASM::VO_BuildASM(std::vector<VO_AAMShape,
std::allocator<VO_AAMShape> > const&, std::vector<VO_AAMShape2DInfo,
std::allocator<VO_AAMShape2DInfo> > const&, VO_FaceParts const&,
float, bool) (VO_ASM.cpp:1071)
==18443==    by 0x810921E:
VO_ASMProfile::VO_BuildASMProfile(std::vector<VO_AAMShape,
std::allocator<VO_AAMShape> > const&, std::vector<_IplImage*,
std::allocator<_IplImage*> > const&, std::vector<VO_AAMShape2DInfo,
std::allocator<VO_AAMShape2DInfo> > const&, VO_FaceParts const&,
unsigned int, unsigned int, unsigned int, unsigned int, bool, unsigned
int) (VO_ASMProfile.cpp:299)
==18443==    by 0x805C7C6:
AAMBuildingGUIFrame::OnStart(wxCommandEvent&)
(AAMBuildingGUIFrame.cpp:901)
==18443==    by 0x4780230: wxAppConsole::HandleEvent(wxEvtHandler*,
void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in
/usr/lib/libwx_baseu-2.8.so.0.5.0)
==18443==    by 0x481F499:
wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.8.so.0.5.0)
==18443==    by 0x48206B3: wxEventHashTable::HandleEvent(wxEvent&,
wxEvtHandler*) (in /usr/lib/libwx_baseu-2.8.so.0.5.0)
==18443==
5) What is this?
==18443==
==18443== 7,868 (1,664 direct, 6,204 indirect) bytes in 5 blocks are
definitely lost in loss record 170 of 189
==18443==    at 0x40270FC: realloc (vg_replace_malloc.c:429)
==18443==    by 0x5AAC951: FcPatternObjectInsertElt (fcpat.c:358)
==18443==    by 0x5AAD3C7: FcPatternObjectAddWithBinding (fcpat.c:515)
==18443==    by 0x5AADA0B: FcPatternObjectAdd (fcpat.c:545)
==18443==    by 0x5AADA4F: FcPatternObjectAddBool (fcpat.c:691)
==18443==    by 0x5AA1E25: FcDefaultSubstitute (fcdefault.c:136)
==18443==    by 0x5F42967:
pango_cairo_fc_font_map_fontset_key_substitute
(pangocairo-fcfontmap.c:93)
==18443==    by 0x59303D4: pango_fc_default_substitute (pangofc-fontmap.c:1586)
==18443==    by 0x59335FE: pango_fc_font_map_load_fontset
(pangofc-fontmap.c:1640)
==18443==    by 0x59F3AD5: pango_font_map_load_fontset (pango-fontmap.c:136)
==18443==    by 0x59F1881: itemize_state_process_run (pango-context.c:1289)
==18443==    by 0x59F1E1E: pango_itemize_with_base_dir (pango-context.c:1467)
==18443==
6) What is this? It seems to be wxWidget memory leakage again?
==18443==
==18443== 116,440 bytes in 101 blocks are possibly lost in loss record
184 of 189
==18443==    at 0x4024EFA: memalign (vg_replace_malloc.c:460)
==18443==    by 0x4024FAE: posix_memalign (vg_replace_malloc.c:569)
==18443==    by 0x5B6CA02: slab_allocator_alloc_chunk (gslice.c:1136)
==18443==    by 0x5B6E1E2: g_slice_alloc (gslice.c:666)
==18443==    by 0x5B2789E: g_array_sized_new (garray.c:86)
==18443==    by 0x5B279B6: g_array_new (garray.c:78)
==18443==    by 0x5B79A8B: g_static_private_set (gthread.c:451)
==18443==    by 0x5B3740F: g_get_filename_charsets (gconvert.c:1185)
==18443==    by 0x5B37480: _g_convert_thread_init (gconvert.c:1290)
==18443==    by 0x5B79D2C: g_thread_init_glib (gthread.c:165)
==18443==    by 0x5B0869C: g_thread_init (gthread-impl.c:355)
==18443==    by 0x44C3502: wxApp::Initialize(int&, wchar_t**) (in
/usr/lib/libwx_gtk2u_core-2.8.so.0.5.0)




After testing my own application, I continued to test a standard demo
downloaded at http://wiki.wxformbuilder.org/Tutorials/UsingWxFormBuilder

I obtained 5 similar Valgrind memory leakage report as:

==29835==
==29835== 156 (36 direct, 120 indirect) bytes in 1 blocks are
definitely lost in loss record 58 of 189
==29835==    at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==29835==    by 0x4ABF548: (within /lib/tls/i686/cmov/libc-2.9.so)
==29835==    by 0x4ABFE25: __nss_database_lookup (in
/lib/tls/i686/cmov/libc-2.9.so)
==29835==    by 0x4044F5B: ???
==29835==    by 0x4045CBE: ???
==29835==    by 0x4A65811: getpwnam_r (in /lib/tls/i686/cmov/libc-2.9.so)
==29835==    by 0x51F8E71: g_get_any_init_do (gutils.c:1631)
==29835==    by 0x51FA924: g_get_home_dir (gutils.c:1782)
==29835==    by 0x4CC3467: gtk_rc_add_initial_default_files (gtkrc.c:557)
==29835==    by 0x4CC606A: _gtk_rc_init (gtkrc.c:896)
==29835==    by 0x4C760B4: post_parse_hook (gtkmain.c:719)
==29835==    by 0x51D2E04: g_option_context_parse (goption.c:1813)
==29835==
==29835==
==29835== 70 bytes in 1 blocks are definitely lost in loss record 74 of 189
==29835==    at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==29835==    by 0x533B5BC: XRRGetOutputInfo (in /usr/lib/libXrandr.so.2.2.0)
==29835==    by 0x4F4CBCC: init_multihead (gdkscreen-x11.c:733)
==29835==    by 0x4F4D2DE: _gdk_x11_screen_new (gdkscreen-x11.c:992)
==29835==    by 0x4F33133: gdk_display_open (gdkdisplay-x11.c:206)
==29835==    by 0x4F0BC44: gdk_display_open_default_libgtk_only (gdk.c:316)
==29835==    by 0x4C75DCE: gtk_init_check (gtkmain.c:957)
==29835==    by 0x44C3241: wxApp::Initialize(int&, wchar_t**) (in
/usr/lib/libwx_gtk2u_core-2.8.so.0.5.0)
==29835==    by 0x47B9B0B: wxEntryStart(int&, wchar_t**) (in
/usr/lib/libwx_baseu-2.8.so.0.5.0)
==29835==    by 0x47B9D6B: wxEntry(int&, wchar_t**) (in
/usr/lib/libwx_baseu-2.8.so.0.5.0)
==29835==    by 0x47B9FA6: wxEntry(int&, char**) (in
/usr/lib/libwx_baseu-2.8.so.0.5.0)
==29835==    by 0x8051B3F: main (wxWidgetsApp.cpp:5)
==29835==
==29835==
==29835== 148 (128 direct, 20 indirect) bytes in 1 blocks are
definitely lost in loss record 100 of 189
==29835==    at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==29835==    by 0x51219D6: FcPatternObjectInsertElt (fcpat.c:367)
==29835==    by 0x51223C7: FcPatternObjectAddWithBinding (fcpat.c:515)
==29835==    by 0x51224DE: FcPatternAppend (fcpat.c:991)
==29835==    by 0x5127FBE: FcEndElement (fcxml.c:2023)
==29835==    by 0x52F4EC3: (within /usr/lib/libexpat.so.1.5.2)
==29835==    by 0x52F5C10: (within /usr/lib/libexpat.so.1.5.2)
==29835==    by 0x52F75EE: (within /usr/lib/libexpat.so.1.5.2)
==29835==    by 0x52F7CE6: (within /usr/lib/libexpat.so.1.5.2)
==29835==    by 0x52EE68B: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2)
==29835==    by 0x5125EFD: FcConfigParseAndLoad (fcxml.c:2552)
==29835==    by 0x5126245: FcConfigParseAndLoad (fcxml.c:2438)
==29835==
==29835==
==29835== 7,868 (1,664 direct, 6,204 indirect) bytes in 5 blocks are
definitely lost in loss record 170 of 189
==29835==    at 0x40270FC: realloc (vg_replace_malloc.c:429)
==29835==    by 0x5121951: FcPatternObjectInsertElt (fcpat.c:358)
==29835==    by 0x51223C7: FcPatternObjectAddWithBinding (fcpat.c:515)
==29835==    by 0x5122A0B: FcPatternObjectAdd (fcpat.c:545)
==29835==    by 0x5122A4F: FcPatternObjectAddBool (fcpat.c:691)
==29835==    by 0x5116E25: FcDefaultSubstitute (fcdefault.c:136)
==29835==    by 0x5351967:
pango_cairo_fc_font_map_fontset_key_substitute
(pangocairo-fcfontmap.c:93)
==29835==    by 0x4FA53D4: pango_fc_default_substitute (pangofc-fontmap.c:1586)
==29835==    by 0x4FA85FE: pango_fc_font_map_load_fontset
(pangofc-fontmap.c:1640)
==29835==    by 0x5068AD5: pango_font_map_load_fontset (pango-fontmap.c:136)
==29835==    by 0x5066881: itemize_state_process_run (pango-context.c:1289)
==29835==    by 0x5066E1E: pango_itemize_with_base_dir (pango-context.c:1467)
==29835==
==29835==
==29835== 80,520 bytes in 79 blocks are possibly lost in loss record 184 of 189
==29835==    at 0x4024EFA: memalign (vg_replace_malloc.c:460)
==29835==    by 0x4024FAE: posix_memalign (vg_replace_malloc.c:569)
==29835==    by 0x51E1A02: slab_allocator_alloc_chunk (gslice.c:1136)
==29835==    by 0x51E31E2: g_slice_alloc (gslice.c:666)
==29835==    by 0x519C89E: g_array_sized_new (garray.c:86)
==29835==    by 0x519C9B6: g_array_new (garray.c:78)
==29835==    by 0x51EEA8B: g_static_private_set (gthread.c:451)
==29835==    by 0x51AC40F: g_get_filename_charsets (gconvert.c:1185)
==29835==    by 0x51AC480: _g_convert_thread_init (gconvert.c:1290)
==29835==    by 0x51EED2C: g_thread_init_glib (gthread.c:165)
==29835==    by 0x517D69C: g_thread_init (gthread-impl.c:355)
==29835==    by 0x44C3502: wxApp::Initialize(int&, wchar_t**) (in
/usr/lib/libwx_gtk2u_core-2.8.so.0.5.0)



So, can anybody help to give me an explanation on why there are these
memory leakage reports? And, how should I avoid the reports? I mean,
even standard  demos of wxWidget will report memory leakages!! Is it
possible that Valgrind itself has some drawbacks?


Cheers
JIA Pei


--
Welcome to Vision Open
http://www.visionopen.com

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Dan Kegel-2]

It's a fact of life with valgrind that you will see
memory leaks from system libraries... you
just have to suppress them and move on.
If you're ambitious, you can make sure the
upstream project knows about the leak.

You might want to check for ready-made suppression
files from other users.  For instance,
http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/suppressions.txt?revision=15913&pathrev=15913
might suppress some of those Fontconfig leaks you're seeing;
download it and pass it to valgrind with --suppressions=suppressions.txt .

The leaks that show up in the wxwindows demo can probably
be ignored, too.  The --generate-suppressions=all flag is helpful
there; you can then copy those suppressions from the log
into your suppressions file.
- Dan

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Tim Post-3]

Hi Dan, Just augmenting your response, I hope you don't mind.

On Fri, 2009-10-16 at 17:33 -0700, Dan Kegel wrote:
> It's a fact of life with valgrind that you will see
> memory leaks from system libraries... you
> just have to suppress them and move on.
> If you're ambitious, you can make sure the
> upstream project knows about the leak.

Many upstream devs will challenge you to say "does it only 'leak once'",
i.e. create a re-usable structure with no obvious means to free it prior
to termination? Or does it leak the same per iteration in some libc
function? (i.e. ancient versions of strtok())

As an example, try reading /etc/passwd with what glibc (and most other
POSIX systems) provide.

In short, if you brought in foo.h .. and getfoo() leaks a static amount
no matter how many times you call it .. you're dealing with a concession
made in your C library (likely, to introduce re-entrant functions that
accomplish the same and / or set errno, depending on the target kernel
and distro).

Cheers,
--Tim

--
Monkey + Typewriter = Echoreply ( http://echoreply.us )


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Valgrind-users@...
https://lists.sourceforge.net/lists/listinfo/valgrind-users