>From what I've heard about memory leaking, this is not unique to the
GTK library. If the rumours are correct, applications like `ls` are
notorious for leaking memory, safe in the knowledge that the OS will
clean up after them.
Excellent work on the enable-debug switch, I'll have to keep this
email for reference.
Thanks,
Michael
On 24/11/2007, c f <[EMAIL PROTECTED]> wrote:
> Hi,
>
> In my opinion the definition what you have given describes well when a
> memory leak can cause serious problems but I would call memory
> leak,any dynamically allocated memory what is not freed when you are
> done with it .
>
> However it is true that OS will cleanup everything when the program
> terminates but this will not help you to find your own leaks.
>
> My real intention with the question was to get certainty that I have
> not missed any cleanup in my application. From the answers it seems to
> me that this (leaking a lot of memory - giving the responsibility to
> the OS to clean it up when the program is terminated) is a normal
> behavior of GTK.
>
> Finally I figured out how can you check the memory leaks.
>
> I share it in a few lines as maybe others will face the same problem:
>
> According to the FAQ (link from Brian) glib caches memory for
> performance improvement (these are the thousands of leaks).
> This kind of functionality can be switched off in the glib by
> configuring the glib with the enable-debug switched on (you should
> also switch on the enable-gc-friendly switch - it will help memory
> profiling tools to detect leaks) and build/install the modified glib.
>
> Run your application with the following environment variables:
> G_SLICE=always-malloc
> G_DEBUG=gc-friendly.
>
> Now those thousands of leaks in GTK will disappear and you can check
> for your real memory leaks.
>
> Thanks,
> Csaba
>
> On Nov 22, 2007 11:43 AM, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
> > > > I have used mtrace to check for memory leaks. In this simple
> > > > application there are more than 5000 memory allocation which is not
> > > > freed.
> >
> > Note that just a dynamic memory allocation that isn't freed before the
> > application terminates is not a leak, in case there still exists a way
> > to access that allocation through static variables (or variables local
> > to main()). You wouldn't call a "static int[10000]" a leak, would you?
> > Nor should you then consider a "static int *p; main (void) { p =
> > malloc(10000); return 0;}" a leak.
> >
> > A leak, by definition, is an allocation that is done repeatedly while
> > the program is running, maybe while the user is performing some
> > repetitive task in the application, and to which no accessible pointer
> > remains. For an allocation to be classified as a leak the allocation
> > should be performed again and again from the same point in code, in a
> > similar context, and forgotten. All this IMHO, of course.
> >
> > --tml
> >
> > _______________________________________________
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
