On Wed, May 23, 2007 at 12:56:33PM +0200, Guenther Meyer wrote: > > Use valgrind. > > > yes, I already was told that. but it floods me with messages, so I can't make > any use of it. is there agood howto or something like that anywhere?
The guide (and quick start guide) on valgrind.org was sufficient for me. If you can read backtraces, it typically prints two backtraces whenever it encounters a problem: of the point where the bad memory access occured and of the point where the memory involved was allocated or freed (in some cases it prints only the former). Well, then there are the problems (and apparent problems) in standard libraries. For start, you can run valgrind on a hello-world style Gtk+ app, let it generate suppressions for all encountered problems, and then use --suppressions to filter these out. You may also want to increase --num-callers and function calls are often nested deeply in Gtk+ apps. > > And use gdb, since you get segfaults, have you tried to at > > least print backtrace to see where it crashes? > > > > gdb program core.12345 > > backtrace > > > yes, but that doesn't really help me... > > Program received signal SIGSEGV, Segmentation fault. > 0x0ef042fc in ?? () from /lib/libc.so.6 > (gdb) backtrace > #0 0x0ef042fc in ?? () from /lib/libc.so.6 > #1 0x0ef041fc in ?? () from /lib/libc.so.6 > #2 0x0ef06874 in ?? () from /lib/libc.so.6 > #3 0x0ef08ad4 in malloc () from /lib/libc.so.6 > #4 0x0f84d2fc in cairo_create () from /usr/lib/libcairo.so.2 > #5 0x0fb07f90 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 > #6 0x0fb08130 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 > #7 0x0fb09d14 in gdk_window_begin_paint_region () > from /usr/lib/libgdk-x11-2.0.so.0 > #8 0x0fd250f8 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 > #9 0x0fb0a1f0 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 > #10 0x0fb0a4e4 in gdk_window_process_all_updates () > from /usr/lib/libgdk-x11-2.0.so.0 > #11 0x0fb0a5b0 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 > #12 0x0f6cbe78 in ?? () from /usr/lib/libglib-2.0.so.0 > #13 0x0f6ce674 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 > #14 0x0f6d2308 in ?? () from /usr/lib/libglib-2.0.so.0 > #15 0x0f6d2774 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 > #16 0x0fd25464 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 > #17 0x10016750 in main (argc=1, argv=0x7fac3824) at gpsdrive.c:5825 It helps to install the debugging info packages, that's corrresponding -dbg, -debug, -debuginfo, or how you distro calls them, to get something better than ??. This look like a problem where the cause and effect are separated -- you g_object_unref()ed something too many times or something like that, and then it got destructed sooner than the holder of the other refences expected, but with luck, where the memory got freed too soon is visible from valgrind's output. Yeti -- http://gwyddion.net/ _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list