|
From: JIA P. <jp...@gm...> - 2009-10-17 00:23:15
|
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 |
|
From: Dan K. <da...@ke...> - 2009-10-17 00:33:37
|
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 |
|
From: Tim P. <ec...@ec...> - 2009-10-17 19:02:03
|
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 ) |