05 Oct 2006

Some days ago, after the pygtk 2.10.2 issue which created a flood of deskbar-applets bugs on bugzilla, I had a discussion on #bugs with guenther about the number of bugs opened against evolution without an useful backtrace.

I already noticed on some occasions than there is cases where gdb produces a correct backtrace and bug-buddy doesn’t get an useful one. I was wondering if the issue is due to bug-buddy and I decided to have an another look with that the pygtk 2.10.2,deskbar crasher

  • From the bug-buddy bug:
    Thread 1 (Thread 47961906685648 (LWP 32518)): #0  0x00002b9efffbeeef in waitpid () from /lib/libpthread.so.0 No symbol table info available. #1  0x000000000000000b in ?? () No symbol table info available. #2  0x38000000006fa750 in ?? () No symbol table info available. #3  0x0000000000000000 in ?? () No symbol table info available. #0  0x00002b9efffbeeef in waitpid () from /lib/libpthread.so.0 
  • The apport backtrace is about the same
  • From gdb when running deskbar-applet with it:
    Thread 1 (Thread 47933151876816 (LWP 32616)): #0  0x00002b984e97b297 in IA__g_type_fundamental (type_id=4035225266131284752) at gtype.c:3098 #1  0x00002b984e961b90 in IA__g_boxed_free (boxed_type=4035225266131284752, boxed=0x7fff5cac71d0) at gboxed.c:453 #2  0x00002b984e82ef85 in init_gobject () from /var/lib/python-support/python2.4/gtk-2.0/gobject/_gobject.so #3  0x000000000044537f in PyTuple_Size () ...

    It looks like a gdb issue then. Attaching gdb after the crash doesn’t produce a correct backtrace in some cases. I’ve tried with gdb 6.4.1 from dapper and gdb 6.4.90 from edgy, no difference. Opinions on that? Any reason why, in some case, gdb can’t get a proper backtrace?