Re: checking for memory leaks in gtk



Hi All,

I got GTK-DFB working on linux x86 PC and ran valgrind with my
application. I got lots of output from valgrind. While comparing
valgrind results for different number of window create and destroy
cycles I found one definite leak record increasing in number of bytes
with increased number of create destroy window cycles with all others
remaining the same. So I guess that this is the one which is causing
the leak. I've pasted that info below:

2700 bytes in 25 blocks are definitely lost in loss record 76 of 91
==21185==    at 0x1B905301: calloc (vg_replace_malloc.c:176)
==21185==    by 0x1BE1945D: fusion_dbg_shcalloc (in
/root/gtk_work/install/lib/libfusion-1.1.so.0.1.0)
==21185==    by 0x1BE08733: dfb_wm_preconfigure_window (in
/root/gtk_work/install/lib/libdirectfb-1.1.so.0.1.0)
==21185==    by 0x1BE04E93: dfb_window_create (in
/root/gtk_work/install/lib/libdirectfb-1.1.so.0.1.0)
==21185==


These are coming from within the DirectFB library. Has anyone observed
leaks in DirectFB 1.1.1 with GTK+?

The other leaks reported are:


ERROR SUMMARY: 2684 errors from 53 contexts (suppressed: 95 from 3)
==21185== malloc/free: in use at exit: 264828 bytes in 5645 blocks.
==21185== malloc/free: 58260 allocs, 52615 frees, 15779745 bytes allocated.
==21185== For counts of detected errors, rerun with: -v
==21185== searching for pointers to 5645 not-freed blocks.
==21185== checked 12240688 bytes.
==21185==
==21185==
==21185== 4 bytes in 1 blocks are definitely lost in loss record 1 of 91
==21185==    at 0x1B904984: malloc (vg_replace_malloc.c:131)
==21185==    by 0x1C0D082D: IA__g_malloc (gmem.c:131)
==21185==    by 0x1BCBD563: IA__gdk_display_open (gdkdisplay-directfb.c:85)
==21185==    by 0x1BC9F364: IA__gdk_display_open_default_libgtk_only (gdk.c:288)
==21185==
==21185==
==21185== 36 bytes in 2 blocks are definitely lost in loss record 16 of 91
==21185==    at 0x1B904984: malloc (vg_replace_malloc.c:131)
==21185==    by 0x9CA6AF: strdup (in /lib/tls/libc-2.3.4.so)
==21185==    by 0x1BD369E4: ???
==21185==    by 0x1BDF6F8B: dfb_input_core_initialize (in
/root/gtk_work/install/lib/libdirectfb-1.1.so.0.1.0)
==21185==
==21185==
==21185== 68 bytes in 1 blocks are possibly lost in loss record 26 of 91
==21185==    at 0x1B905301: calloc (vg_replace_malloc.c:176)
==21185==    by 0x1B8F2705: __GI__dl_allocate_tls (in /lib/ld-2.3.4.so)
==21185==    by 0x1BE355BF: pthread_create (vg_libpthread.c:1155)
==21185==    by 0x1BE29B5A: direct_thread_create (in
/root/gtk_work/install/lib/libdirect-1.1.so.0.1.0)
==21185==
==21185==
==21185== 72 bytes in 2 blocks are definitely lost in loss record 28 of 91
==21185==    at 0x1B905301: calloc (vg_replace_malloc.c:176)
==21185==    by 0x1BE22884: direct_log_create (in
/root/gtk_work/install/lib/libdirect-1.1.so.0.1.0)
==21185==    by 0x1BE21942: direct_initialize (in
/root/gtk_work/install/lib/libdirect-1.1.so.0.1.0)
==21185==    by 0x1BDBD949: DirectFBCreate (in
/root/gtk_work/install/lib/libdirectfb-1.1.so.0.1.0)
==21185==
==21185==
==21185== 800 bytes in 20 blocks are possibly lost in loss record 65 of 91
==21185==    at 0x1B905301: calloc (vg_replace_malloc.c:176)
==21185==    by 0x1C0D07C3: IA__g_malloc0 (gmem.c:150)
==21185==    by 0x1C0824F3: type_node_any_new_W (gtype.c:342)
==21185==    by 0x1C082580: type_node_fundamental_new_W (gtype.c:447)
==21185==
==21185==
==21185== 2700 bytes in 25 blocks are definitely lost in loss record 76 of 91
==21185==    at 0x1B905301: calloc (vg_replace_malloc.c:176)
==21185==    by 0x1BE1945D: fusion_dbg_shcalloc (in
/root/gtk_work/install/lib/libfusion-1.1.so.0.1.0)
==21185==    by 0x1BE08733: dfb_wm_preconfigure_window (in
/root/gtk_work/install/lib/libdirectfb-1.1.so.0.1.0)
==21185==    by 0x1BE04E93: dfb_window_create (in
/root/gtk_work/install/lib/libdirectfb-1.1.so.0.1.0)
==21185==
==21185==
==21185== 2832 bytes in 1 blocks are possibly lost in loss record 77 of 91
==21185==    at 0x1B9054B9: memalign (vg_replace_malloc.c:217)
==21185==    by 0x1B8F26BD: __GI__dl_allocate_tls (in /lib/ld-2.3.4.so)
==21185==    by 0x1BE355BF: pthread_create (vg_libpthread.c:1155)
==21185==    by 0x1BE29B5A: direct_thread_create (in
/root/gtk_work/install/lib/libdirect-1.1.so.0.1.0)
==21185==
==21185==
==21185== 5120 bytes in 20 blocks are definitely lost in loss record 84 of 91
==21185==    at 0x1B9053EE: realloc (vg_replace_malloc.c:197)
==21185==    by 0x1B91CC9E: FcPatternObjectInsertElt (fcpat.c:357)
==21185==    by 0x1B91D8D7: FcPatternObjectAddWithBinding (fcpat.c:514)
==21185==    by 0x1B91DCD2: FcPatternObjectAdd (fcpat.c:544)
==21185==
==21185== LEAK SUMMARY:
==21185==    definitely lost: 7932 bytes in 50 blocks.
==21185==    possibly lost:   3700 bytes in 22 blocks.
==21185==    still reachable: 252796 bytes in 5571 blocks.
==21185==         suppressed: 400 bytes in 2 blocks.
==21185== Reachable blocks (those to which a pointer was found) are not shown.
==21185== To see them, rerun with: --show-reachable=yes

Regards,
Harinandan S


On Mon, May 19, 2008 at 5:01 PM,  <jcupitt gmail com> wrote:
> 2008/5/19 Harinandan S <harinandans gmail com>:
>> Anyway, I digged some more details about the leak. When i stepped
>> through the code i found that gdk_window_destroy_notify function in
>> gdkwindow-directfb.c which is called when the window is really gone is
>> not being called.
>>
>> I also found a quite old bug which exactly resembles what I am observing:
>> http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00048.html
>
> It does sound like a bug. I see you filed a report, I guess you just
> need to wait for a gtk-fb dev to see it.
>
> I guess you saw this page?
>
> http://www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB
>
> It has some build notes for gtk-fb
>
> John
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]