Re: memory leak in gtk
c f wrote: snip I have checked the GTK documentation and it states that gtk_exit free all resources allocated for GTK+. gtk_exit is depricated and using exit is recommended. I have tested both but non of them improved the situation (still more than 5000 leaks). This is normal. GTK is not going to clean up, nor can it, every single allocation it makes. However this is not a problem. GTK will not leak more and more memory over time. Only sunk resources are leaked, such as global data structures. Most people who try to find leaks in their GTK programs will use a tool like valgrind with a large gtk-specific suppression file. A memory leak is a memory leak, but it's only those leaks that accumulate that are a problem. Sometimes I'll use a memory profiler and make sure my program's memory use doesn't increase beyond bounds. One trick is to rename main() and then write a temporary main() that calls the real main thousands of times. Over time the memory use should never exceed a certain ceiling. Of course with GTK being used for interactive things, this is a bit difficult. Anyway, google around for valgrind suppression files for GTK apps and then give your app a shot. You should readily be able to find your own leaks, that really do matter. Please could you help if I missed some cleanup in my application or what is happening? Thanks, Csaba ___ 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
Re: {Spam?} Re: memory leak in gtk
On Sat, 2007-11-24 at 10:09 +0100, Vincent Torri wrote: 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. and if someone calls 'ls' iteratively in his program ? if you call 'ls' in a child process the leak happens in you child process, so it will be cleaned up by the OS when the child process terminates and the parent reaps it. the memory will be reassigned to other applications, thus is *not* a leak. in a real leak the OS cannot reassign the leaked memory because your application is still the owner. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: {Spam?} Re: memory leak in gtk
On Sat, 24 Nov 2007, Michael Lamothe wrote: 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. and if someone calls 'ls' iteratively in his program ? Vincent Torri ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: {Spam?} Re: memory leak in gtk
Vincent Torri escreveu: On Sat, 24 Nov 2007, Michael Lamothe wrote: 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. and if someone calls 'ls' iteratively in his program ? When a process finish, the OS clean up memory. However, on some cases, the cost to freeing the memory is greater than let to the OS. -- Yours Truly, Junior Polegato A pilgrim of problems; A parchment of solutions! Professional Page: http://www.juniorpolegato.com.br ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: {Spam?} Re: {Spam?} Re: memory leak in gtk
Vincent Torri escreveu: On Sat, 24 Nov 2007, Junior Polegato - GTK+ GTKmm wrote: Vincent Torri escreveu: On Sat, 24 Nov 2007, Michael Lamothe wrote: 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. and if someone calls 'ls' iteratively in his program ? When a process finish, the OS clean up memory. However, on some cases, the cost to freeing the memory is greater than let to the OS. and ? You have definitely a leak there. Calling, in your program (with the exec() functions family), iteratively and infinitely a program that leaks can crash your system. 'ls' is maybe not a good example, but i'm sure you see what I mean ;) I said on some cases, like ls. On this case you have described, the cost is the system crash. -- Yours Truly, Junior Polegato A pilgrim of problems; A parchment of solutions! Professional Page: http://www.juniorpolegato.com.br ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak in gtk
Junior Polegato - GTK+ GTKmm wrote: Vincent Torri escreveu: On Sat, 24 Nov 2007, Junior Polegato - GTK+ GTKmm wrote: Vincent Torri escreveu: On Sat, 24 Nov 2007, Michael Lamothe wrote: 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. and if someone calls 'ls' iteratively in his program ? When a process finish, the OS clean up memory. However, on some cases, the cost to freeing the memory is greater than let to the OS. and ? You have definitely a leak there. Calling, in your program (with the exec() functions family), iteratively and infinitely a program that leaks can crash your system. 'ls' is maybe not a good example, but i'm sure you see what I mean ;) I said on some cases, like ls. On this case you have described, the cost is the system crash. Generally, programming without leaks can take more time and is also the best code solution, but sometimes leaks are okay and you'll get your program done sooner. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak in gtk
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[1] a leak, would you?
Nor should you then consider a static int *p; main (void) { p =
malloc(1); 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
Re: memory leak in gtk
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[1] a leak, would you?
Nor should you then consider a static int *p; main (void) { p =
malloc(1); 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
Re: memory leak in gtk
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[1] a leak, would you?
Nor should you then consider a static int *p; main (void) { p =
malloc(1); 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
memory leak in gtk
Hi,
I have made a simple application with a top level window:
#include gtk/gtk.h
#include mcheck.h
gboolean OnDeleteHandler(GtkWidget *sender,
GdkEvent *event,
gpointer data)
{
return FALSE;
}
void OnDestroyHandler(GtkWidget *sender, gpointer data)
{
gtk_main_quit();
}
int main(int argc, char *argv[])
{
mtrace();
gtk_init(argc, argv);
GtkWidget *mainWindow = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(mainWindow), delete_event,
G_CALLBACK(OnDeleteHandler), NULL);
g_signal_connect(G_OBJECT(mainWindow), destroy,
G_CALLBACK(OnDestroyHandler), NULL);
gtk_widget_show_all(mainWindow);
gtk_main();
// gtk_exit(0);
// exit(0);
return EXIT_SUCCESS;
}
I have used mtrace to check for memory leaks. In this simple
application there are more than 5000 memory allocation which is not
freed.
I have checked the GTK documentation and it states that gtk_exit free
all resources allocated for GTK+. gtk_exit is depricated and using
exit is recommended. I have tested both but non of them improved the
situation (still more than 5000 leaks).
Please could you help if I missed some cleanup in my application or
what is happening?
Thanks,
Csaba
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak in gtk
I'm no master profiler but I think that you'll want to put a
gtk_widget_destroy(mainWindow); after the gtk_main();. You really
don't need to do this because it will be destroyed when the
application terminates 0.01 seconds after that line. But if you feel
you must then go for it. I also like to tie-off loose ends.
Thanks,
Michael
On 22/11/2007, c f [EMAIL PROTECTED] wrote:
Hi,
I have made a simple application with a top level window:
#include gtk/gtk.h
#include mcheck.h
gboolean OnDeleteHandler(GtkWidget *sender,
GdkEvent *event,
gpointer data)
{
return FALSE;
}
void OnDestroyHandler(GtkWidget *sender, gpointer data)
{
gtk_main_quit();
}
int main(int argc, char *argv[])
{
mtrace();
gtk_init(argc, argv);
GtkWidget *mainWindow = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(mainWindow), delete_event,
G_CALLBACK(OnDeleteHandler), NULL);
g_signal_connect(G_OBJECT(mainWindow), destroy,
G_CALLBACK(OnDestroyHandler), NULL);
gtk_widget_show_all(mainWindow);
gtk_main();
// gtk_exit(0);
// exit(0);
return EXIT_SUCCESS;
}
I have used mtrace to check for memory leaks. In this simple
application there are more than 5000 memory allocation which is not
freed.
I have checked the GTK documentation and it states that gtk_exit free
all resources allocated for GTK+. gtk_exit is depricated and using
exit is recommended. I have tested both but non of them improved the
situation (still more than 5000 leaks).
Please could you help if I missed some cleanup in my application or
what is happening?
Thanks,
Csaba
___
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
Re: memory leak in gtk
Hi Michael,
Thanks for your suggestion.
Actually I have not mentioned but I also tried to decrease the ref
count of the mainWindow (just to be sure). In theory it is already
destroyed at this point as the main quit is called in the destoyed
handler of the main window. In that case (unref), GTK showed the
assertion: object is not a valid g object so the mainWindow was
destroyed correctly.
Anyhow I have tried to apply your suggestion but mainWindow does not
exists at this point.
You really
don't need to do this because it will be destroyed when the
application terminates 0.01 seconds after that line.
I do not know if this (thousands of memory leaks) is normal in a GTK
application, but it is quite hard to find your own memory leaks if
there are a lot from other components.
Thanks,
Csaba
On Nov 22, 2007 12:10 AM, Michael Lamothe [EMAIL PROTECTED] wrote:
I'm no master profiler but I think that you'll want to put a
gtk_widget_destroy(mainWindow); after the gtk_main();. You really
don't need to do this because it will be destroyed when the
application terminates 0.01 seconds after that line. But if you feel
you must then go for it. I also like to tie-off loose ends.
Thanks,
Michael
On 22/11/2007, c f [EMAIL PROTECTED] wrote:
Hi,
I have made a simple application with a top level window:
#include gtk/gtk.h
#include mcheck.h
gboolean OnDeleteHandler(GtkWidget *sender,
GdkEvent *event,
gpointer data)
{
return FALSE;
}
void OnDestroyHandler(GtkWidget *sender, gpointer data)
{
gtk_main_quit();
}
int main(int argc, char *argv[])
{
mtrace();
gtk_init(argc, argv);
GtkWidget *mainWindow = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(mainWindow), delete_event,
G_CALLBACK(OnDeleteHandler), NULL);
g_signal_connect(G_OBJECT(mainWindow), destroy,
G_CALLBACK(OnDestroyHandler), NULL);
gtk_widget_show_all(mainWindow);
gtk_main();
// gtk_exit(0);
// exit(0);
return EXIT_SUCCESS;
}
I have used mtrace to check for memory leaks. In this simple
application there are more than 5000 memory allocation which is not
freed.
I have checked the GTK documentation and it states that gtk_exit free
all resources allocated for GTK+. gtk_exit is depricated and using
exit is recommended. I have tested both but non of them improved the
situation (still more than 5000 leaks).
Please could you help if I missed some cleanup in my application or
what is happening?
Thanks,
Csaba
___
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
Re: memory leak in gtk
On Wed, 21 Nov 2007 20:15:25 +0100 c f 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. See: http://www.gtk.org/faq/#AEN703 I have checked the GTK documentation and it states that gtk_exit free all resources allocated for GTK+. gtk_exit is depricated and using exit is recommended. It's deprecated for a reason -- it doesn't free all memory allocated by gtk (or glib, or gobject, or gdk). It's not possible to do so. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak with gtk+-2.8.20-r1
On Fri, 2006-08-04 at 13:25 +0200, gwenj wrote:
Hello,
I use gtk+ for my soft's graphic interface.
But valgrind make an log file containing approximately 22700 lines for an
simple source code like :
#include gtk/gtk.h
int main(int argc, char **argv) {
gtk_init(argc, argv);
GtkWidget *win= gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(win), destroy, G_CALLBACK(gtk_main_quit),
NULL);
gtk_widget_show_all(win);
gtk_main();
return EXIT_SUCCESS;
}
I've just compiled and run this code snippet with valgrind, and the
results are on my system (Fedora):
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 1)
malloc/free: in use at exit: 0 bytes in 0 blocks.
malloc/free: 30 allocs, 30 frees, 1,981 bytes allocated.
It's difficult to write more simple code...
Well if you catch the preprocessor output you'll realize that things are
not always as simpler as they look. Your code grows to 32603 lines
before compilation :)
--
Iago Rubio
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak with gtk+-2.8.20-r1
On Sun, Aug 06, 2006 at 09:45:00AM +0200, Iago Rubio wrote:
I've just compiled and run this code snippet with valgrind, and the
results are on my system (Fedora):
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 1)
malloc/free: in use at exit: 0 bytes in 0 blocks.
malloc/free: 30 allocs, 30 frees, 1,981 bytes allocated.
1981 bytes allocated?! What is the part you are not telling
us?
Taking stock Fedora Core 5 installation (updated) and compling
just
/* Avoid preprocessed size talks */
void g_type_init(void);
int main(void)
{
g_type_init();
return 0;
}
with
gcc -o simple simple.c -lgobject-2.0
I get numbers like:
x86_64: malloc/free: 413 allocs, 194 frees, 376,464 bytes allocated.
i386: malloc/free: 415 allocs, 194 frees, 192,000 bytes allocated.
So please enlighten me how you achieve only 1981 bytes
allocated by a complete Gtk+ program on Fedora. (There are
a few tricks I can imagine, but they generally render the
specification `Gtk+' or `Fedora' irrelevant, modify valgrind
behaviour, make the compiler to build a different program,
etc.)
Yeti
--
Anonyms eat their boogers.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak with gtk+-2.8.20-r1
On Sun, 06 Aug 2006 13:53:46 +0200 Iago Rubio [EMAIL PROTECTED] wrote: On Sun, 2006-08-06 at 11:37 +0200, gwenhael wrote: On Sun, 06 Aug 2006 09:45:00 +0200 Iago Rubio [EMAIL PROTECTED] wrote: On Fri, 2006-08-04 at 13:25 +0200, gwenj wrote: Hello, I use gtk+ for my soft's graphic interface. But valgrind make an log file containing approximately 22700 lines for an simple source code like [snip] I've just compiled and run this code snippet with valgrind, and the results are on my system (Fedora): ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 1) malloc/free: in use at exit: 0 bytes in 0 blocks. malloc/free: 30 allocs, 30 frees, 1,981 bytes allocated. [snip] what is your version of gtk+, glib, glibc and gcc? I run valgrind with : valgrind -v --tool=memcheck --trace-children=yes --db-attach=no --log-file-exactly=error-valgrind.log --leak-check=yes --leak-resolution=high --show-reachable=yes ./test I run valgrind ./test. That's what I was trying to tell you :) Your first post - ... valgrind made an log file containing ... - have not enough information to help to track what was going on when you checked the leak. Others persons, running Gentoo, have the same problem. I think that this is problem relative to Gentoo or with an certain version of libraries needed by gtk+. Running on Fedora5 gcc-4.1.1-1, gtk2-2.8.18-1, glib2-2.10.3 and using your valgrind options the output is: LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks. possibly lost: 48,440 bytes in 49 blocks. still reachable: 160,448 bytes in 2,921 blocks. suppressed: 0 bytes in 0 blocks. I don't know if it matches the output on your system as you didn't posted anywhere reachable the valgrind log file, but if it doesn't match, it could be a Gentoo problem. The 'possibly lost' bites means - AFAIK - that exists pointers to the interior of the analyzed block that may have pointed to the start of the block and have been moved, among other possible causes, such as debug padding - where a pointer to an object is returned as the start + padding of the memory block as with pymalloc and python debug builds. From this output I would not bet that exists - for sure - a memory leak on gtk, but it may be investigated further. ITOH if you are sure the leak exists, the best place to discuss it is on the gtk-devel list. Cheers. -- Iago Rubio ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list The result to valgrind is : ==29096== LEAK SUMMARY: ==29096==definitely lost: 0 bytes in 0 blocks. ==29096== possibly lost: 800 bytes in 20 blocks. ==29096==still reachable: 41,380 bytes in 618 blocks. ==29096== suppressed: 0 bytes in 0 blocks. --29096-- memcheck: sanity checks: 33 cheap, 2 expensive --29096-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --29096-- memcheck: auxmaps: 0 searches, 0 comparisons --29096-- memcheck: secondaries: 38 issued (2432k, 2M) --29096-- memcheck: secondaries: 115 accessible and distinguished (7360k, 7M) --29096-- tt/tc: 12,535 tt lookups requiring 13,041 probes --29096-- tt/tc: 12,535 fast-cache updates, 3 flushes --29096-- translate: new5,802 (124,805 - 2,017,944; ratio 161:10) [0 scs] --29096-- translate: dumped 0 (0 - ??) --29096-- translate: discarded 7 (166 - ??) --29096-- scheduler: 1,683,892 jumps (bb entries). --29096-- scheduler: 33/8,957 major/minor sched events. --29096--sanity: 34 cheap, 2 expensive checks. --29096--exectx: 30,011 lists, 665 contexts (avg 0 per list) --29096--exectx: 1,999 searches, 1,344 full compares (672 per 1000) --29096--exectx: 0 cmp2, 159 cmp4, 37,600 cmpAll Gwenhaël ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak with gtk+-2.8.20-r1
On Sun, 6 Aug 2006, Iago Rubio wrote: The 'possibly lost' bites means - AFAIK - that exists pointers to the interior of the analyzed block that may have pointed to the start of the block and have been moved, among other possible causes, such as debug padding - where a pointer to an object is returned as the start + padding of the memory block as with pymalloc and python debug builds. GTK+/Gnome doesn't release everything on exit normally -- and that's a feature! Why waste time on piecemeal clean up of things the operating system is going to clean up anyway much faster? You even risk slow paging in from swap in order to do that useless clean up! (I think that used to be a real performance bug with Netscape/Mozilla.) There is an environment variable that can be set to a specific value to tell the libraries to clean up their stuff anyway so the leaks in an application can stand out. Can't remember what the variable is called or what value to set it to. -Peter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak with gtk+-2.8.20-r1
On Sun, 06 Aug 2006 09:45:00 +0200
Iago Rubio [EMAIL PROTECTED] wrote:
On Fri, 2006-08-04 at 13:25 +0200, gwenj wrote:
Hello,
I use gtk+ for my soft's graphic interface.
But valgrind make an log file containing approximately 22700 lines for an
simple source code like :
#include gtk/gtk.h
int main(int argc, char **argv) {
gtk_init(argc, argv);
GtkWidget *win= gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(win), destroy, G_CALLBACK(gtk_main_quit),
NULL);
gtk_widget_show_all(win);
gtk_main();
return EXIT_SUCCESS;
}
I've just compiled and run this code snippet with valgrind, and the
results are on my system (Fedora):
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 1)
malloc/free: in use at exit: 0 bytes in 0 blocks.
malloc/free: 30 allocs, 30 frees, 1,981 bytes allocated.
It's difficult to write more simple code...
Well if you catch the preprocessor output you'll realize that things are
not always as simpler as they look. Your code grows to 32603 lines
before compilation :)
--
Iago Rubio
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Hello,
what is you version of gtk+, glib, glibc and gcc?
Others persons, running Gentoo have the same problem.
Gwenhaël
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak with gtk+-2.8.20-r1
On Sun, 06 Aug 2006 13:53:46 +0200 Iago Rubio [EMAIL PROTECTED] wrote: On Sun, 2006-08-06 at 11:37 +0200, gwenhael wrote: On Sun, 06 Aug 2006 09:45:00 +0200 Iago Rubio [EMAIL PROTECTED] wrote: On Fri, 2006-08-04 at 13:25 +0200, gwenj wrote: Hello, I use gtk+ for my soft's graphic interface. But valgrind make an log file containing approximately 22700 lines for an simple source code like [snip] I've just compiled and run this code snippet with valgrind, and the results are on my system (Fedora): ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 1) malloc/free: in use at exit: 0 bytes in 0 blocks. malloc/free: 30 allocs, 30 frees, 1,981 bytes allocated. [snip] what is your version of gtk+, glib, glibc and gcc? I run valgrind with : valgrind -v --tool=memcheck --trace-children=yes --db-attach=no --log-file-exactly=error-valgrind.log --leak-check=yes --leak-resolution=high --show-reachable=yes ./test I run valgrind ./test. That's what I was trying to tell you :) Your first post - ... valgrind made an log file containing ... - have not enough information to help to track what was going on when you checked the leak. Others persons, running Gentoo, have the same problem. I think that this is problem relative to Gentoo or with an certain version of libraries needed by gtk+. Running on Fedora5 gcc-4.1.1-1, gtk2-2.8.18-1, glib2-2.10.3 and using your valgrind options the output is: LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks. possibly lost: 48,440 bytes in 49 blocks. still reachable: 160,448 bytes in 2,921 blocks. suppressed: 0 bytes in 0 blocks. I don't know if it matches the output on your system as you didn't posted anywhere reachable the valgrind log file, but if it doesn't match, it could be a Gentoo problem. The 'possibly lost' bites means - AFAIK - that exists pointers to the interior of the analyzed block that may have pointed to the start of the block and have been moved, among other possible causes, such as debug padding - where a pointer to an object is returned as the start + padding of the memory block as with pymalloc and python debug builds. From this output I would not bet that exists - for sure - a memory leak on gtk, but it may be investigated further. ITOH if you are sure the leak exists, the best place to discuss it is on the gtk-devel list. Cheers. -- Iago Rubio ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list The result to valgrind is : ==29096== LEAK SUMMARY: ==29096==definitely lost: 0 bytes in 0 blocks. ==29096== possibly lost: 800 bytes in 20 blocks. ==29096==still reachable: 41,380 bytes in 618 blocks. ==29096== suppressed: 0 bytes in 0 blocks. --29096-- memcheck: sanity checks: 33 cheap, 2 expensive --29096-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --29096-- memcheck: auxmaps: 0 searches, 0 comparisons --29096-- memcheck: secondaries: 38 issued (2432k, 2M) --29096-- memcheck: secondaries: 115 accessible and distinguished (7360k, 7M) --29096-- tt/tc: 12,535 tt lookups requiring 13,041 probes --29096-- tt/tc: 12,535 fast-cache updates, 3 flushes --29096-- translate: new5,802 (124,805 - 2,017,944; ratio 161:10) [0 scs] --29096-- translate: dumped 0 (0 - ??) --29096-- translate: discarded 7 (166 - ??) --29096-- scheduler: 1,683,892 jumps (bb entries). --29096-- scheduler: 33/8,957 major/minor sched events. --29096--sanity: 34 cheap, 2 expensive checks. --29096--exectx: 30,011 lists, 665 contexts (avg 0 per list) --29096--exectx: 1,999 searches, 1,344 full compares (672 per 1000) --29096--exectx: 0 cmp2, 159 cmp4, 37,600 cmpAll Gwenhaël ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak with gtk+-2.8.20-r1
On Sun, 2006-08-06 at 11:38 +0200, David Nečas (Yeti) wrote: On Sun, Aug 06, 2006 at 09:45:00AM +0200, Iago Rubio wrote: I've just compiled and run this code snippet with valgrind, and the results are on my system (Fedora): ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 1) malloc/free: in use at exit: 0 bytes in 0 blocks. malloc/free: 30 allocs, 30 frees, 1,981 bytes allocated. 1981 bytes allocated?! Yes sorry. Look like my fingers slipped a bit and I copied the results of valgrind test instead of the output of valgrind ./test. -- Iago Rubio ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak with gtk+-2.8.20-r1
On Sun, 2006-08-06 at 14:07 +0200, gwenj wrote: The result to valgrind is : ==29096== LEAK SUMMARY: ==29096==definitely lost: 0 bytes in 0 blocks. Nothing malloc'ed and not freed. ==29096== possibly lost: 800 bytes in 20 blocks. This may be investigated further, but I bet they are false positives. ==29096==still reachable: 41,380 bytes in 618 blocks. That's completely normal. Surely they're static variables holding pointers to freed memory. From this output, I don't see an obvious leak. -- Iago Rubio ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak with gtk+-2.8.20-r1
==29096==still reachable: 41,380 bytes in 618 blocks. That's completely normal. Surely they're static variables holding pointers to freed memory. maybe this comes from glib memory allocator. I have such results with gstreamer too Vincent ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memory leak with gtk+-2.8.20-r1
On Sun, 2006-08-06 at 20:55 +0200, Vincent Torri wrote: ==29096==still reachable: 41,380 bytes in 618 blocks. That's completely normal. Surely they're static variables holding pointers to freed memory. maybe this comes from glib memory allocator. I have such results with gstreamer too Glib can be compiled to use a leak-detector-friendly allocator rather than the pool on that it currently uses. It is my experience that you'll get unreliable valgrind data without recompiling glib From http://developer.gnome.org/doc/API/2.0/glib/glib-building.html: --disable-gc-friendly and --enable-gc-friendly. By default, and with --disable-gc-friendly as well, Glib does not clear the memory for certain objects before they are freed. For example, Glib may decide to recycle GList nodes by putting them in a free list. However, memory profiling and debugging tools like Valgrind work better if an application does not keep dangling pointers to freed memory (even though these pointers are no longer dereferenced), or invalid pointers inside uninitialized memory. Also this option seem to be appicable: --disable-mem-pools and --enable-mem-pools. Many small chunks of memory are often allocated via collective pools in GLib and are cached after release to speed up reallocations. For sparse memory systems this behaviour is often inferior, so memory pools can be disabled to avoid excessive caching and force atomic maintenance of chunks through the g_malloc() and g_free() functions. Vincent ___ 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
memory leak with gtk+-2.8.20-r1
Hello,
I use gtk+ for my soft's graphic interface.
But valgrind make an log file containing approximately 22700 lines for an
simple source code like :
#include gtk/gtk.h
int main(int argc, char **argv) {
gtk_init(argc, argv);
GtkWidget *win= gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(win), destroy, G_CALLBACK(gtk_main_quit),
NULL);
gtk_widget_show_all(win);
gtk_main();
return EXIT_SUCCESS;
}
It's difficult to write more simple code...
I've made many searchs on the web but nothing information to resolve this
problem.
I've recompiling all with : emerge -e world
downgrading all of X parts and gtk+ glib. But the result are the same.
Visibly the big part of error are in gtk_init - gdk_display_open and
XOpenDisplay in libX11.
When the program is closed the display is not destroyed.
But the size of log to valgrind is very big (1.6M) and it's impossible to join
with mail.
Someone has the same problem or an solution to solve this leak of memory?
Thank you very much.
Gwenhaël
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
memory leak with gtk+-2.8.20-r1
Hello,
I use gtk+ for my soft's graphic interface.
But valgrind make an log file containing approximately 22700 lines for an
simple source code like :
#include gtk/gtk.h
int main(int argc, char **argv) {
gtk_init(argc, argv);
GtkWidget *win= gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(win), destroy, G_CALLBACK(gtk_main_quit),
NULL);
gtk_widget_show_all(win);
gtk_main();
return EXIT_SUCCESS;
}
It's difficult to write more simple code...
I've made many searchs on the web but nothing information to resolve this
problem.
I've recompiling all with : emerge -e world
downgrading all of X parts and gtk+ glib. But the result are the same.
Visibly the big part of error are in gtk_init - gdk_display_open and
XOpenDisplay in libX11.
When the program is closed the display is not destroyed.
But the size of log to valgrind is very big (1.6M) and it's impossible to join
with mail.
Someone has the same problem or an solution to solve this leak of memory?
Thank you very much.
Gwenhaël
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
