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@xxxxxxxxx> 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@xxxxxxxxx> wrote: >> 2008/5/19 Harinandan S <harinandans@xxxxxxxxx>: >>> 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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
