From: <Rap...@po...> - 2011-06-18 11:40:34
|
Quoting Andrew Benton <b3...@gm...> from ml.softs.gtk-gnutella.users: :On Sat, 18 Jun 2011 06:45:57 +0200 :Roland Häder <r.h...@gm...> wrote: : :> Reading symbols from :/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so...(no debugging :symbols found)...done. :> Loaded symbols for /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so :> 0x00007fd3e23a6bce in __libc_waitpid (pid=<value optimized out>, :stat_loc=0x7fff0697856c, options=<value optimized out>) at :../sysdeps/unix/sysv/linux/waitpid.c:32 :> 32 ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory. :> in ../sysdeps/unix/sysv/linux/waitpid.c :> (gdb) #0 0x00007fd3e23a6bce in __libc_waitpid (pid=<value optimized out>, :stat_loc=0x7fff0697856c, options=<value optimized out>) at :../sysdeps/unix/sysv/linux/waitpid.c:32 :> #1 0x000000000067a6bf in crash_invoke_inspector (signo=6, cwd=0x7fd3e5669050 :"/home/quix0r/.gtk-gnutella/crashes") at crash.c:849 : :libpixbufloader-png.so is part of gdk-pixbuf. waitpid.c is part of :glibc. To my untrained eye it doesn't look to me as though this crash :is due to code in gtk-gnutella. Actually it is probably a bug in gtk-gnutella (the VMM layer). The fact that the stacktrace begins with waitpid() is due to the fact that the stack trace is produced by gtk-gnutella itself, during crashing: it forks a child to trace its parent, and the parent is of course in waitpid(), which is why you have the upper stack "polluted" with self-inspecting code. Your trained eye was good, you just missed that self-inspection part :-) Regarding the bug itself, well... VMM bugs are extremely hard to debug. I'm going to pass on this one for now, unless you get frequent and extremely reproducable crashes from the VMM layer, at which point it is possible to add additional tracing code to pinpoint the problem. Raphael |