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 in GTK+ DFB backend 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 defining it this leak has not been observed. On Tue, May 20, 2008 at 3:07 PM, Harinandan S <[EMAIL PROTECTED]> wrote: > On Tue, May 20, 2008 at 1:54 PM, Attilio Fiandrotti > <[EMAIL PROTECTED]> wrote: >> I remember a significant memory leak was addressed some times ago by >> means of a patch provided by Simon Lanzmich [1]. > > This file and the one I have as part of GTK+ 2.12.2 are identical. > >> I wonder wether that leak really is a leak and whether is related to >> gtk/dfb or dfb. >> >> regards >> >> Attilio >> >> [1] >> http://svn.gnome.org/viewvc/gtk%2B/trunk/gdk/directfb/gdkwindow-directfb.c?revision=18459&view=markup&sortby=date >> >> Harinandan S ha scritto: >>> Hi All, >>> >>> I ran my GTK-DFB application on x86 linux on vmware with valgrind to >>> check for memory leak. I observe memory leak when window is created >>> and destroyed. When window is created memory is allocated and not >>> freed when its destroyed. This accumulates and eventually after many >>> create destroy window cycles application is crashing. When i look at >>> valgrind output I observe only one leak record which keeps increasing >>> as the create destroy cycles are increased. I've pasted this 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== >>> >>> I guess window destroy is not freeing memory. I am using DirectFB >>> 1.1.1 with GTK+ 2.12.2. >>> >>> Regards, >>> Harinandan >>> >>> >>> On Thu, May 15, 2008 at 1:36 PM, Harinandan S <[EMAIL PROTECTED]> wrote: >>>> Hi All, >>>> >>>> I am observing large amount of memory leaks while using GTK+ 2.12.2 >>>> over DirectFB 1.1.1 on MontaVista linux on TI Davinci. In my >>>> application i have multiple windows and when i create a window memory >>>> is allocated and accumulates when i destroy the window. Memory leak is >>>> not observed while running the same application on Xwindow backend . >>>> >>>> Has anyone observed memory leaks in GTK+ on DirectFB? >>>> >>>> -- >>>> Regards, >>>> Harinandan S >>>> >>> >>> _______________________________________________ >>> directfb-users mailing list >>> directfb-users@directfb.org >>> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users >>> >> >> >> _______________________________________________ >> directfb-users mailing list >> directfb-users@directfb.org >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users >> > -- > Regards, > Harinandan S > -- Regards, Harinandan S _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
