|
From: <de...@cs...> - 2006-08-20 09:48:49
Attachments:
valgrind.tmp
|
Hello, Could anyone offer help or advice on debugging mysterious gtk-related memory leaks and errors reported by valgrind when checking a threaded GTK+ program? The primary "potential" leak seems to be a sizeable chunk in g_thread_init, and there are quite a few errors from various unknown contexts (including g_module_open). Please take a look at the attached valgrind --leak-check=full output, and/or offer general advice on pursuing such errors and leaks, which are almost undoubtedly caused by my code, yet do not appear to come from any context I am familiar with. Is there some procedure for cleaning up g_threads, apart from adding a window "destroy" handler like gtk_main_quit? Thanks, David |
|
From: David E. <tw...@us...> - 2006-08-20 10:08:41
|
On Sun, 2006-08-20 at 05:48 -0400, David Ellis wrote: > Hello, > > Could anyone offer help or advice on debugging mysterious gtk-related memory > leaks and errors reported by valgrind when checking a threaded GTK+ > program? The primary "potential" leak seems to be a sizeable chunk in > g_thread_init, and there are quite a few errors from various unknown > contexts (including g_module_open). > > Please take a look at the attached valgrind --leak-check=full output, > and/or offer general advice on pursuing such errors and leaks, which are > almost undoubtedly caused by my code, yet do not appear to come from any > context I am familiar with. Is there some procedure for cleaning up > g_threads, apart from adding a window "destroy" handler like > gtk_main_quit? Maybe you should set G_SLICE=always-malloc in the environment in order to make valgrind more useful: http://developer.gnome.org/doc/API/2.0/glib/glib-running.html \David -- |
|
From: Julian S. <js...@ac...> - 2006-08-20 12:17:37
|
> Maybe you should set G_SLICE=always-malloc in the environment in order > to make valgrind more useful: > > http://developer.gnome.org/doc/API/2.0/glib/glib-running.html I agree; from a guess I'd say that glib is using a private allocator, which confuses the issue. Unrelatedly .. It looks like the 'valgrind-3.1.1-Debian' you are using has been shipped without a set of suppressions suitable for getting rid of all the complaints of the form ==3722== Conditional jump or move depends on uninitialised value(s) ==3722== at 0x401139F: (within /lib/ld-2.3.6.so) ==3722== by 0x4006ACE: (within /lib/ld-2.3.6.so) ==3722== by 0x48A14AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==3722== by 0x400BA5E: (within /lib/ld-2.3.6.so) which is a shame. It may be that if you install debug info packages for /lib/ld-2.3.6.so and/or libc-2.3.6.so, that noise will go away. J |
|
From: David E. <de...@cs...> - 2006-09-06 02:56:55
Attachments:
val18.log
|
I tried it with the debug info packages and malloc, and now there are only a few X/gtk errors. Anyone have suggestions on how to approach those? Maybe someone on the gtk-app-devel-list? Thanks, David Julian Seward wrote: >>Maybe you should set G_SLICE=always-malloc in the environment in order >>to make valgrind more useful: >> >> http://developer.gnome.org/doc/API/2.0/glib/glib-running.html >> >> > >I agree; from a guess I'd say that glib is using a private allocator, >which confuses the issue. > >Unrelatedly .. > >It looks like the 'valgrind-3.1.1-Debian' you are using has been >shipped without a set of suppressions suitable for getting rid of >all the complaints of the form > >==3722== Conditional jump or move depends on uninitialised value(s) >==3722== at 0x401139F: (within /lib/ld-2.3.6.so) >==3722== by 0x4006ACE: (within /lib/ld-2.3.6.so) >==3722== by 0x48A14AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) >==3722== by 0x400BA5E: (within /lib/ld-2.3.6.so) > >which is a shame. It may be that if you install debug info packages >for /lib/ld-2.3.6.so and/or libc-2.3.6.so, that noise will go away. > >J > > |