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
