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
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to