Re: checking for memory leaks in gtk



Hi All,

I found out the reason for leak. It was from GTK+ DirectFB backend and
not from DirectFB library. Functions which were responsible for
de-allocating memory in DirectFB were not called. This resulted in
accumulation of memory.

The functions for deallocating memory was under an
  #if (DIRECTFB_MAJOR_VERSION >= 1)
and I was using DirectFB 1.1.1. But DIRECTFB_MAJOR_VERSION was not
defined anywhere in Gtk+ 2.12.2 so the compiler was taking it to be 0
by default and thus functions were not being called to de-allocate
memory.

After I defined it, I am not observing that huge leak which was
crashing the application. Though still some minor leaks are observed
while running a test program for several minutes.

Thanks a lot for all the help.

Regards,
Harinandan



On Tue, May 20, 2008 at 12:09 PM, Harinandan S <harinandans gmail com> wrote:
> 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
>>
>



-- 
Regards,
Harinandan S


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