Does wxWidgets 2.8 leak memory?

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Post Reply
CyberSlayer
In need of some credit
In need of some credit
Posts: 7
Joined: Wed Feb 21, 2007 6:19 pm

Does wxWidgets 2.8 leak memory?

Post by CyberSlayer » Sun Feb 25, 2007 10:20 pm

I am using KDevelop 3.3.4, gcc 4.1.2 and wxWidgets 2.8 (default build) on Ubuntu 6.10 with the GNOME desktop manager. When I create the hello world wxWidgets project in KDevelop and run it under Valgrind (I just closed the app immediately after it came up) numerous errors are detected including several memory leaks (see the end of this post for the valgrind output). I have had the same thing happen when I entered the hello world example in the wxWidgets documentation and tested it for leaks. So what is going on here? Does wxWidgets have memory leak problems or am I doing something wrong?

Valgrind Output:
==30938== LEAK SUMMARY:
==30938== definitely lost: 2,386 bytes in 14 blocks.
==30938== possibly lost: 82,896 bytes in 59 blocks.
==30938== still reachable: 1,650,333 bytes in 10,839 blocks.
==30938== suppressed: 0 bytes in 0 blocks.

Note that only the leak summary is shown due to the length of the output.

Thanks

Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria » Mon Feb 26, 2007 1:08 am

Well from the summary nothing can be told - leaks could come from GTK, other libs, etc.

You'll need to analyse all output thouroughly and determine which ones belong to wxWidgets if any.

Though, i would too be interested to know if wxWidgets was Valgrinded - though probably not. IMO a lot of programs would be better if they were valgrinded, however this is also very time consuming

CyberSlayer
In need of some credit
In need of some credit
Posts: 7
Joined: Wed Feb 21, 2007 6:19 pm

Post by CyberSlayer » Mon Feb 26, 2007 1:44 am

It looks like GTK is causing some of the leaks (but not all of them). I also tried a hello world GTK project and it also leaked a lot of memory. Has anyone experienced leaks on other platforms that don't use GTK?

It looks like wxWidgets has leaks too. Some of the leaks in the valgrind output are caused by the wxWidgets .so lib.

Thanks

Full Valgrind Output:
==8539== 26 bytes in 1 blocks are definitely lost in loss record 26 of 163
==8539== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==8539== by 0x5AD692A: wxSetEnv(wxString const&, char const*) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==8539== by 0x5478845: wxApp::Initialize(int&, char**) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539== by 0x5A75B3C: wxEntryStart(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==8539== by 0x5A75D7A: wxEntry(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==8539== by 0x408A4B: main (test.cpp:9)
==8539==
==8539==
==8539== 36 bytes in 1 blocks are definitely lost in loss record 38 of 163
==8539== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==8539== by 0x74E360C: (within /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x74E3E66: (within /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x74E48B2: XcursorXcFileLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x74E49B8: XcursorFileLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x74E5204: XcursorLibraryLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x74E5B47: XcursorTryShapeCursor (in /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x784B1B3: XCreateGlyphCursor (in /usr/lib/libX11.so.6.2.0)
==8539== by 0x784B710: XCreateFontCursor (in /usr/lib/libX11.so.6.2.0)
==8539== by 0x6AE584B: gdk_cursor_new_for_display (in /usr/lib/libgdk-x11-2.0.so.0.1000.6)
==8539== by 0x5480A1A: wxCursor::wxCursor(int) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539== by 0x5547AF1: wxStockGDI::GetCursor(wxStockGDI::Item) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539==
==8539==
==8539== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 58 of 163
==8539== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==8539== by 0x62985B0: (within /lib/libc-2.4.so)
==8539== by 0x6298CFE: __nss_database_lookup (in /lib/libc-2.4.so)
==8539== by 0x90DB5CF: ???
==8539== by 0x90DCA46: ???
==8539== by 0x624EB14: getpwnam_r (in /lib/libc-2.4.so)
==8539== by 0x7DA546F: (within /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7DA67BF: g_get_home_dir (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x67939FB: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x679673C: _gtk_rc_init (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x674FD69: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x7D8C020: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539==
==8539==
==8539== 1,600 bytes in 20 blocks are possibly lost in loss record 119 of 163
==8539== at 0x4A1FB37: calloc (vg_replace_malloc.c:279)
==8539== by 0x7D86AE1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7A2DC7E: (within /usr/lib/libgobject-2.0.so.0.1200.4)
==8539== by 0x7A2DDCE: (within /usr/lib/libgobject-2.0.so.0.1200.4)
==8539== by 0x7A2E3BC: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.1200.4)
==8539== by 0x6AC608E: gdk_pre_parse_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.1000.6)
==8539== by 0x674FE12: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x7D8BE96: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x674FA4E: gtk_parse_args (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x674FAA8: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x547872B: wxApp::Initialize(int&, char**) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539== by 0x5A75B3C: wxEntryStart(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==8539==
==8539==
==8539== 2,032 bytes in 1 blocks are definitely lost in loss record 125 of 163
==8539== at 0x4A1FB37: calloc (vg_replace_malloc.c:279)
==8539== by 0x7D86AE1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D95D0A: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D63429: g_ptr_array_sized_new (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D803BA: g_main_context_new (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D8055F: g_main_context_default (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D819A4: g_source_attach (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D81A71: g_idle_add_full (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x5478B3B: wxapp_install_idle_handler() (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539== by 0x5478C9D: wxApp::wxApp() (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539== by 0x409C60: testapp::testapp() (test.h:13)
==8539== by 0x408A7C: wxCreateApp() (test.cpp:9)
==8539==
==8539==
==8539== 81,296 bytes in 39 blocks are possibly lost in loss record 158 of 163
==8539== at 0x4A1FA22: memalign (vg_replace_malloc.c:332)
==8539== by 0x4A1FA7B: posix_memalign (vg_replace_malloc.c:386)
==8539== by 0x7D94C40: (within /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D95F5B: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D96075: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x771255E: (within /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x770FBCB: pango_log2vis_get_embedding_levels (in /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x770131D: (within /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x7702044: pango_itemize_with_base_dir (in /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x77091DF: (within /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x7709D1C: (within /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x770AC84: pango_layout_get_pixel_extents (in /usr/lib/libpango-1.0.so.0.1400.5)
==8539==
==8539== LEAK SUMMARY:
==8539== definitely lost: 2,146 bytes in 4 blocks.
==8539== indirectly lost: 240 bytes in 10 blocks.
==8539== possibly lost: 82,896 bytes in 59 blocks.
==8539== still reachable: 1,650,413 bytes in 10,841 blocks.
==8539== suppressed: 0 bytes in 0 blocks.
==8539== Reachable blocks (those to which a pointer was found) are not shown.
==8539== To see them, rerun with: --show-reachable=yes

Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria » Mon Feb 26, 2007 1:56 am

only the first one seems to be related to wxWidgets

CyberSlayer
In need of some credit
In need of some credit
Posts: 7
Joined: Wed Feb 21, 2007 6:19 pm

Post by CyberSlayer » Mon Feb 26, 2007 2:08 am

Yes. I don't know why I put some leaks since there is only one wxWidgets leak. But this was just for the hello world app. More leaks would probably show up for something more complex.

User avatar
Ryan Norton
Moderator
Moderator
Posts: 1319
Joined: Mon Aug 30, 2004 6:01 pm

Post by Ryan Norton » Mon Feb 26, 2007 2:46 am

Well, the first is the result of

Code: Select all

    // the string will be free()d by libc
    char *buf = (char *)malloc(strlen(p) + 1);
    strcpy(buf, p);

    return putenv(buf) == 0;
Apple/BSD's just allocates its own data and copies it
http://www.opensource.apple.com/darwins ... n/putenv.c

So that would explain the leak - but there is an interesting thread
http://sourceware.org/ml/libc-hacker/19 ... 00005.html

and other sources on the web use the opposite - so it looks like implementations are different.....

EDIT: Here we go, this seems to explain it
http://www.gnu.org/software/autoconf/ma ... ility.html

interesting nonetheless
[Mostly retired moderator, still check in to clean up some stuff]

framepointer
Super wx Problem Solver
Super wx Problem Solver
Posts: 264
Joined: Mon Aug 07, 2006 3:25 pm
Location: Baia Mare, Romania
Contact:

Post by framepointer » Mon Feb 26, 2007 6:32 pm

CyberSlayer wrote:It looks like GTK is causing some of the leaks (but not all of them). I also tried a hello world GTK project and it also leaked a lot of memory. Has anyone experienced leaks on other platforms that don't use GTK?

It looks like wxWidgets has leaks too. Some of the leaks in the valgrind output are caused by the wxWidgets .so lib.

Thanks

Full Valgrind Output:
==8539== 26 bytes in 1 blocks are definitely lost in loss record 26 of 163
==8539== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==8539== by 0x5AD692A: wxSetEnv(wxString const&, char const*) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==8539== by 0x5478845: wxApp::Initialize(int&, char**) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539== by 0x5A75B3C: wxEntryStart(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==8539== by 0x5A75D7A: wxEntry(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==8539== by 0x408A4B: main (test.cpp:9)
==8539==
==8539==
==8539== 36 bytes in 1 blocks are definitely lost in loss record 38 of 163
==8539== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==8539== by 0x74E360C: (within /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x74E3E66: (within /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x74E48B2: XcursorXcFileLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x74E49B8: XcursorFileLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x74E5204: XcursorLibraryLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x74E5B47: XcursorTryShapeCursor (in /usr/lib/libXcursor.so.1.0.2)
==8539== by 0x784B1B3: XCreateGlyphCursor (in /usr/lib/libX11.so.6.2.0)
==8539== by 0x784B710: XCreateFontCursor (in /usr/lib/libX11.so.6.2.0)
==8539== by 0x6AE584B: gdk_cursor_new_for_display (in /usr/lib/libgdk-x11-2.0.so.0.1000.6)
==8539== by 0x5480A1A: wxCursor::wxCursor(int) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539== by 0x5547AF1: wxStockGDI::GetCursor(wxStockGDI::Item) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539==
==8539==
==8539== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 58 of 163
==8539== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==8539== by 0x62985B0: (within /lib/libc-2.4.so)
==8539== by 0x6298CFE: __nss_database_lookup (in /lib/libc-2.4.so)
==8539== by 0x90DB5CF: ???
==8539== by 0x90DCA46: ???
==8539== by 0x624EB14: getpwnam_r (in /lib/libc-2.4.so)
==8539== by 0x7DA546F: (within /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7DA67BF: g_get_home_dir (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x67939FB: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x679673C: _gtk_rc_init (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x674FD69: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x7D8C020: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539==
==8539==
==8539== 1,600 bytes in 20 blocks are possibly lost in loss record 119 of 163
==8539== at 0x4A1FB37: calloc (vg_replace_malloc.c:279)
==8539== by 0x7D86AE1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7A2DC7E: (within /usr/lib/libgobject-2.0.so.0.1200.4)
==8539== by 0x7A2DDCE: (within /usr/lib/libgobject-2.0.so.0.1200.4)
==8539== by 0x7A2E3BC: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.1200.4)
==8539== by 0x6AC608E: gdk_pre_parse_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.1000.6)
==8539== by 0x674FE12: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x7D8BE96: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x674FA4E: gtk_parse_args (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x674FAA8: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==8539== by 0x547872B: wxApp::Initialize(int&, char**) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539== by 0x5A75B3C: wxEntryStart(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==8539==
==8539==
==8539== 2,032 bytes in 1 blocks are definitely lost in loss record 125 of 163
==8539== at 0x4A1FB37: calloc (vg_replace_malloc.c:279)
==8539== by 0x7D86AE1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D95D0A: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D63429: g_ptr_array_sized_new (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D803BA: g_main_context_new (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D8055F: g_main_context_default (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D819A4: g_source_attach (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D81A71: g_idle_add_full (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x5478B3B: wxapp_install_idle_handler() (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539== by 0x5478C9D: wxApp::wxApp() (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==8539== by 0x409C60: testapp::testapp() (test.h:13)
==8539== by 0x408A7C: wxCreateApp() (test.cpp:9)
==8539==
==8539==
==8539== 81,296 bytes in 39 blocks are possibly lost in loss record 158 of 163
==8539== at 0x4A1FA22: memalign (vg_replace_malloc.c:332)
==8539== by 0x4A1FA7B: posix_memalign (vg_replace_malloc.c:386)
==8539== by 0x7D94C40: (within /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D95F5B: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x7D96075: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==8539== by 0x771255E: (within /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x770FBCB: pango_log2vis_get_embedding_levels (in /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x770131D: (within /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x7702044: pango_itemize_with_base_dir (in /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x77091DF: (within /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x7709D1C: (within /usr/lib/libpango-1.0.so.0.1400.5)
==8539== by 0x770AC84: pango_layout_get_pixel_extents (in /usr/lib/libpango-1.0.so.0.1400.5)
==8539==
==8539== LEAK SUMMARY:
==8539== definitely lost: 2,146 bytes in 4 blocks.
==8539== indirectly lost: 240 bytes in 10 blocks.
==8539== possibly lost: 82,896 bytes in 59 blocks.
==8539== still reachable: 1,650,413 bytes in 10,841 blocks.
==8539== suppressed: 0 bytes in 0 blocks.
==8539== Reachable blocks (those to which a pointer was found) are not shown.
==8539== To see them, rerun with: --show-reachable=yes
Dont worry about those. In a large app you'll get many such errors, most of them are related to GTK and the libs it uses pango/cairo/etc.
Most annoying are the read errors from wxStrings, at least in wx 2.6.3 i get those almost everywhere where wxStrings are not allocated on the heap.

Just skip those errors. Most of them are related to stuff that's done only once, so no biggie. Better to have 2000 bytes loss on app init than a 1 byte leak in some idle events or something.


Regards
Software is like sex,
It's better when it's free.
~Linus Torvalds

CyberSlayer
In need of some credit
In need of some credit
Posts: 7
Joined: Wed Feb 21, 2007 6:19 pm

Not All the Leaks Are Only One-Time Occurrences

Post by CyberSlayer » Tue Feb 27, 2007 1:54 am

For instance, wxMessageBox also appears to have leaks. I ran the hello world app I mentioned several more times and noticed that if I close the app before the MenuBar comes up on the screen more memory is leaked than if I wait for the MenuBar to come up and then close the app. I also discovered that every time about on the file menu is clicked, the number of leaks (under definitely lost in the valgrind output) when the app is closed increases by 1 block. So it appears the there is at least one other leak here to (maybe wxMessageBox?) although it doesn't look like wxWidgets is causing this leak itself.

Valgrind Output when the app is closed after the MenuBar appears on the screen:
==27045== ERROR SUMMARY: 37 errors from 24 contexts (suppressed: 34 from 1)
==27045== malloc/free: in use at exit: 1,735,615 bytes in 10,912 blocks.
==27045== malloc/free: 132,387 allocs, 121,475 frees, 33,206,259 bytes allocated.
==27045== For counts of detected errors, rerun with: -v
==27045== searching for pointers to 10,912 not-freed blocks.
==27045== checked 2,825,400 bytes.
==27045==
==27045==
==27045== 26 bytes in 1 blocks are definitely lost in loss record 26 of 163
==27045== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==27045== by 0x5AD692A: wxSetEnv(wxString const&, char const*) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==27045== by 0x5478845: wxApp::Initialize(int&, char**) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27045== by 0x5A75B3C: wxEntryStart(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==27045== by 0x5A75D7A: wxEntry(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==27045== by 0x408A4B: main (test.cpp:9)
==27045==
==27045==
==27045== 36 bytes in 1 blocks are definitely lost in loss record 38 of 163
==27045== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==27045== by 0x74E360C: (within /usr/lib/libXcursor.so.1.0.2)
==27045== by 0x74E3E66: (within /usr/lib/libXcursor.so.1.0.2)
==27045== by 0x74E48B2: XcursorXcFileLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==27045== by 0x74E49B8: XcursorFileLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==27045== by 0x74E5204: XcursorLibraryLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==27045== by 0x74E5B47: XcursorTryShapeCursor (in /usr/lib/libXcursor.so.1.0.2)
==27045== by 0x784B1B3: XCreateGlyphCursor (in /usr/lib/libX11.so.6.2.0)
==27045== by 0x784B710: XCreateFontCursor (in /usr/lib/libX11.so.6.2.0)
==27045== by 0x6AE584B: gdk_cursor_new_for_display (in /usr/lib/libgdk-x11-2.0.so.0.1000.6)
==27045== by 0x5480A1A: wxCursor::wxCursor(int) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27045== by 0x5547AF1: wxStockGDI::GetCursor(wxStockGDI::Item) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27045==
==27045==
==27045== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 58 of 163
==27045== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==27045== by 0x62985B0: (within /lib/libc-2.4.so)
==27045== by 0x6298CFE: __nss_database_lookup (in /lib/libc-2.4.so)
==27045== by 0x90DB5CF: ???
==27045== by 0x90DCA46: ???
==27045== by 0x624EB14: getpwnam_r (in /lib/libc-2.4.so)
==27045== by 0x7DA546F: (within /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x7DA67BF: g_get_home_dir (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x67939FB: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27045== by 0x679673C: _gtk_rc_init (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27045== by 0x674FD69: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27045== by 0x7D8C020: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045==
==27045==
==27045== 1,600 bytes in 20 blocks are possibly lost in loss record 119 of 163
==27045== at 0x4A1FB37: calloc (vg_replace_malloc.c:279)
==27045== by 0x7D86AE1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x7A2DC7E: (within /usr/lib/libgobject-2.0.so.0.1200.4)
==27045== by 0x7A2DDCE: (within /usr/lib/libgobject-2.0.so.0.1200.4)
==27045== by 0x7A2E3BC: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.1200.4)
==27045== by 0x6AC608E: gdk_pre_parse_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.1000.6)
==27045== by 0x674FE12: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27045== by 0x7D8BE96: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x674FA4E: gtk_parse_args (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27045== by 0x674FAA8: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27045== by 0x547872B: wxApp::Initialize(int&, char**) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27045== by 0x5A75B3C: wxEntryStart(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==27045==
==27045==
==27045== 2,032 bytes in 1 blocks are definitely lost in loss record 125 of 163
==27045== at 0x4A1FB37: calloc (vg_replace_malloc.c:279)
==27045== by 0x7D86AE1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x7D95D0A: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x7D63429: g_ptr_array_sized_new (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x7D803BA: g_main_context_new (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x7D8055F: g_main_context_default (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x7D819A4: g_source_attach (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x7D81A71: g_idle_add_full (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x5478B3B: wxapp_install_idle_handler() (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27045== by 0x5478C9D: wxApp::wxApp() (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27045== by 0x409C60: testapp::testapp() (test.h:13)
==27045== by 0x408A7C: wxCreateApp() (test.cpp:9)
==27045==
==27045==
==27045== 81,296 bytes in 39 blocks are possibly lost in loss record 158 of 163
==27045== at 0x4A1FA22: memalign (vg_replace_malloc.c:332)
==27045== by 0x4A1FA7B: posix_memalign (vg_replace_malloc.c:386)
==27045== by 0x7D94C40: (within /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x7D95F5B: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x7D96075: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==27045== by 0x771255E: (within /usr/lib/libpango-1.0.so.0.1400.5)
==27045== by 0x770FBCB: pango_log2vis_get_embedding_levels (in /usr/lib/libpango-1.0.so.0.1400.5)
==27045== by 0x770131D: (within /usr/lib/libpango-1.0.so.0.1400.5)
==27045== by 0x7702044: pango_itemize_with_base_dir (in /usr/lib/libpango-1.0.so.0.1400.5)
==27045== by 0x77091DF: (within /usr/lib/libpango-1.0.so.0.1400.5)
==27045== by 0x7709D1C: (within /usr/lib/libpango-1.0.so.0.1400.5)
==27045== by 0x770AC84: pango_layout_get_pixel_extents (in /usr/lib/libpango-1.0.so.0.1400.5)
==27045==
==27045== LEAK SUMMARY:
==27045== definitely lost: 2,146 bytes in 4 blocks.
==27045== indirectly lost: 240 bytes in 10 blocks.
==27045== possibly lost: 82,896 bytes in 59 blocks.
==27045== still reachable: 1,650,333 bytes in 10,839 blocks.
==27045== suppressed: 0 bytes in 0 blocks.
==27045== Reachable blocks (those to which a pointer was found) are not shown.
==27045== To see them, rerun with: --show-reachable=yes

Valgrind Output for when about on the file menu is clicked once before closing:
==27079== ERROR SUMMARY: 46 errors from 24 contexts (suppressed: 34 from 1)
==27079== malloc/free: in use at exit: 2,475,987 bytes in 20,045 blocks.
==27079== malloc/free: 177,499 allocs, 157,454 frees, 36,029,743 bytes allocated.
==27079== For counts of detected errors, rerun with: -v
==27079== searching for pointers to 20,045 not-freed blocks.
==27079== checked 3,378,288 bytes.
==27079==
==27079==
==27079== 26 bytes in 1 blocks are definitely lost in loss record 26 of 166
==27079== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==27079== by 0x5AD692A: wxSetEnv(wxString const&, char const*) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==27079== by 0x5478845: wxApp::Initialize(int&, char**) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27079== by 0x5A75B3C: wxEntryStart(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==27079== by 0x5A75D7A: wxEntry(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==27079== by 0x408A4B: main (test.cpp:9)
==27079==
==27079==
==27079== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 57 of 166
==27079== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==27079== by 0x62985B0: (within /lib/libc-2.4.so)
==27079== by 0x6298CFE: __nss_database_lookup (in /lib/libc-2.4.so)
==27079== by 0x90DB5CF: ???
==27079== by 0x90DCA46: ???
==27079== by 0x624EB14: getpwnam_r (in /lib/libc-2.4.so)
==27079== by 0x7DA546F: (within /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x7DA67BF: g_get_home_dir (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x67939FB: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27079== by 0x679673C: _gtk_rc_init (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27079== by 0x674FD69: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27079== by 0x7D8C020: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079==
==27079==
==27079== 72 bytes in 2 blocks are definitely lost in loss record 62 of 166
==27079== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==27079== by 0x74E360C: (within /usr/lib/libXcursor.so.1.0.2)
==27079== by 0x74E3E66: (within /usr/lib/libXcursor.so.1.0.2)
==27079== by 0x74E48B2: XcursorXcFileLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==27079== by 0x74E49B8: XcursorFileLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==27079== by 0x74E5204: XcursorLibraryLoadImages (in /usr/lib/libXcursor.so.1.0.2)
==27079== by 0x74E5B47: XcursorTryShapeCursor (in /usr/lib/libXcursor.so.1.0.2)
==27079== by 0x784B1B3: XCreateGlyphCursor (in /usr/lib/libX11.so.6.2.0)
==27079== by 0x784B710: XCreateFontCursor (in /usr/lib/libX11.so.6.2.0)
==27079== by 0x6AE584B: gdk_cursor_new_for_display (in /usr/lib/libgdk-x11-2.0.so.0.1000.6)
==27079== by 0x5480A1A: wxCursor::wxCursor(int) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27079== by 0x5547AF1: wxStockGDI::GetCursor(wxStockGDI::Item) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27079==
==27079==
==27079== 1,600 bytes in 20 blocks are possibly lost in loss record 120 of 166
==27079== at 0x4A1FB37: calloc (vg_replace_malloc.c:279)
==27079== by 0x7D86AE1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x7A2DC7E: (within /usr/lib/libgobject-2.0.so.0.1200.4)
==27079== by 0x7A2DDCE: (within /usr/lib/libgobject-2.0.so.0.1200.4)
==27079== by 0x7A2E3BC: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.1200.4)
==27079== by 0x6AC608E: gdk_pre_parse_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.1000.6)
==27079== by 0x674FE12: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27079== by 0x7D8BE96: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x674FA4E: gtk_parse_args (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27079== by 0x674FAA8: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27079== by 0x547872B: wxApp::Initialize(int&, char**) (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27079== by 0x5A75B3C: wxEntryStart(int&, char**) (in /usr/local/lib/libwx_base-2.8.so.0.0.0)
==27079==
==27079==
==27079== 2,032 bytes in 1 blocks are definitely lost in loss record 127 of 166
==27079== at 0x4A1FB37: calloc (vg_replace_malloc.c:279)
==27079== by 0x7D86AE1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x7D95D0A: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x7D63429: g_ptr_array_sized_new (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x7D803BA: g_main_context_new (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x7D8055F: g_main_context_default (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x7D819A4: g_source_attach (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x7D81A71: g_idle_add_full (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x5478B3B: wxapp_install_idle_handler() (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27079== by 0x5478C9D: wxApp::wxApp() (in /usr/local/lib/libwx_gtk2_core-2.8.so.0.0.0)
==27079== by 0x409C60: testapp::testapp() (test.h:13)
==27079== by 0x408A7C: wxCreateApp() (test.cpp:9)
==27079==
==27079==
==27079== 92,448 bytes in 46 blocks are possibly lost in loss record 159 of 166
==27079== at 0x4A1FA22: memalign (vg_replace_malloc.c:332)
==27079== by 0x4A1FA7B: posix_memalign (vg_replace_malloc.c:386)
==27079== by 0x7D94C40: (within /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x7D95F5B: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x7D96075: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==27079== by 0x771255E: (within /usr/lib/libpango-1.0.so.0.1400.5)
==27079== by 0x770FBCB: pango_log2vis_get_embedding_levels (in /usr/lib/libpango-1.0.so.0.1400.5)
==27079== by 0x770131D: (within /usr/lib/libpango-1.0.so.0.1400.5)
==27079== by 0x7702044: pango_itemize_with_base_dir (in /usr/lib/libpango-1.0.so.0.1400.5)
==27079== by 0x77091DF: (within /usr/lib/libpango-1.0.so.0.1400.5)
==27079== by 0x7709D1C: (within /usr/lib/libpango-1.0.so.0.1400.5)
==27079== by 0x770AC84: pango_layout_get_pixel_extents (in /usr/lib/libpango-1.0.so.0.1400.5)
==27079==
==27079== LEAK SUMMARY:
==27079== definitely lost: 2,182 bytes in 5 blocks.
==27079== indirectly lost: 240 bytes in 10 blocks.
==27079== possibly lost: 94,048 bytes in 66 blocks.
==27079== still reachable: 2,379,517 bytes in 19,964 blocks.
==27079== suppressed: 0 bytes in 0 blocks.
==27079== Reachable blocks (those to which a pointer was found) are not shown.
==27079== To see them, rerun with: --show-reachable=yes

Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria » Tue Feb 27, 2007 2:02 am

in /usr/lib/libpango
in /usr/lib/libgtk
in /usr/lib/libglib
in /usr/lib/libX11
in /usr/lib/libgdk
again, most of these seem unrelated to wxWidgets

CyberSlayer
In need of some credit
In need of some credit
Posts: 7
Joined: Wed Feb 21, 2007 6:19 pm

Post by CyberSlayer » Tue Feb 27, 2007 2:47 am

Yes I said in my last post that the additional leak was not due to wxWidgets.

framepointer
Super wx Problem Solver
Super wx Problem Solver
Posts: 264
Joined: Mon Aug 07, 2006 3:25 pm
Location: Baia Mare, Romania
Contact:

Post by framepointer » Tue Feb 27, 2007 10:45 am

Even if pango, cairo, etc is not directly related to wx, some leaks might be the reault of improper use, allocation/freeing of some resources in the wx.

I'm curios if other gtk based apps leak memory the same way a wx does (when using same methods, etc).
Software is like sex,
It's better when it's free.
~Linus Torvalds

Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria » Tue Feb 27, 2007 1:13 pm

Unfortunately everything leaks memory when passed in valgrind, so i think it is safe to assume that wxWidgets as well as GTK both leak memory somewhere

CyberSlayer
In need of some credit
In need of some credit
Posts: 7
Joined: Wed Feb 21, 2007 6:19 pm

Post by CyberSlayer » Tue Feb 27, 2007 6:32 pm

framepointer wrote:Even if pango, cairo, etc is not directly related to wx, some leaks might be the reault of improper use, allocation/freeing of some resources in the wx.

I'm curios if other gtk based apps leak memory the same way a wx does (when using same methods, etc).
I doubt the app was written improperly since it was a hello world app. I also get similar result when I when I use the hello world app on this site and the one in KDevelop.

I don't know about how a comparable app in GTK would behave (because I don't know GTK and I don't have one); the GTK hello world app is simpler than the wxWidgets hello world app but it is also leaky (although not as bad as the wxWidgets one).
Unfortunately everything leaks memory when passed in valgrind, so i think it is safe to assume that wxWidgets as well as GTK both leak memory somewhere
That is not true. It seems that pretty much all GUI apps on Linux have leaks but run valgrind on some command line apps and you will find that not all of them leak memory.

The reason the GUI apps are leaky is because the GUI libraries they use leak memory. Why aren't these leaks fixed?

valgrind output for the KDevelop GTK hello world app:
==27286== ERROR SUMMARY: 22 errors from 18 contexts (suppressed: 34 from 1)
==27286== malloc/free: in use at exit: 470,756 bytes in 5,082 blocks.
==27286== malloc/free: 11,088 allocs, 6,006 frees, 1,307,450 bytes allocated.
==27286== For counts of detected errors, rerun with: -v
==27286== searching for pointers to 5,082 not-freed blocks.
==27286== checked 1,597,376 bytes.
==27286==
==27286==
==27286== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 50 of 120
==27286== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==27286== by 0x78135B0: (within /lib/libc-2.4.so)
==27286== by 0x7813CFE: __nss_database_lookup (in /lib/libc-2.4.so)
==27286== by 0x867A5CF: ???
==27286== by 0x867BA46: ???
==27286== by 0x77C9B14: getpwnam_r (in /lib/libc-2.4.so)
==27286== by 0x715C46F: (within /usr/lib/libglib-2.0.so.0.1200.4)
==27286== by 0x715D7BF: g_get_home_dir (in /usr/lib/libglib-2.0.so.0.1200.4)
==27286== by 0x54449FB: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27286== by 0x544773C: _gtk_rc_init (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27286== by 0x5400D69: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27286== by 0x7143020: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1200.4)
==27286==
==27286==
==27286== 1,600 bytes in 20 blocks are possibly lost in loss record 97 of 120
==27286== at 0x4A1FB37: calloc (vg_replace_malloc.c:279)
==27286== by 0x713DAE1: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==27286== by 0x6DE4C7E: (within /usr/lib/libgobject-2.0.so.0.1200.4)
==27286== by 0x6DE4DCE: (within /usr/lib/libgobject-2.0.so.0.1200.4)
==27286== by 0x6DE53BC: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.1200.4)
==27286== by 0x5C0B08E: gdk_pre_parse_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.1000.6)
==27286== by 0x5400E12: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27286== by 0x7142E96: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1200.4)
==27286== by 0x5400A4E: gtk_parse_args (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27286== by 0x5400AA8: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27286== by 0x5400AD8: gtk_init (in /usr/lib/libgtk-x11-2.0.so.0.1000.6)
==27286== by 0x4DB5B7F: Gtk::Main::init(int*, char***, bool) (in /usr/lib/libgtkmm-2.4.so.1.0.30)
==27286==
==27286==
==27286== 37,648 bytes in 15 blocks are possibly lost in loss record 117 of 120
==27286== at 0x4A1FA22: memalign (vg_replace_malloc.c:332)
==27286== by 0x4A1FA7B: posix_memalign (vg_replace_malloc.c:386)
==27286== by 0x714BC40: (within /usr/lib/libglib-2.0.so.0.1200.4)
==27286== by 0x714CF5B: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.4)
==27286== by 0x714D075: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.1200.4)
==27286== by 0x6DEC44E: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.1200.4)
==27286== by 0x6DD528E: g_param_spec_internal (in /usr/lib/libgobject-2.0.so.0.1200.4)
==27286== by 0x6DD6EF9: g_param_spec_double (in /usr/lib/libgobject-2.0.so.0.1200.4)
==27286== by 0x5C2117F: (within /usr/lib/libgdk-x11-2.0.so.0.1000.6)
==27286== by 0x6DEBD1B: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.1200.4)
==27286== by 0x6DEC0EA: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.1200.4)
==27286== by 0x6DD2769: g_object_newv (in /usr/lib/libgobject-2.0.so.0.1200.4)
==27286==
==27286== LEAK SUMMARY:
==27286== definitely lost: 52 bytes in 1 blocks.
==27286== indirectly lost: 240 bytes in 10 blocks.
==27286== possibly lost: 39,248 bytes in 35 blocks.
==27286== still reachable: 431,216 bytes in 5,036 blocks.
==27286== suppressed: 0 bytes in 0 blocks.
==27286== Reachable blocks (those to which a pointer was found) are not shown.
==27286== To see them, rerun with: --show-reachable=yes

Post Reply