Squeeze Dolphin Crash - need debug symbols

[Nick Boyce]

I had a Dolphin crash the other day, but the crash handler was unable to
obtain a useful stack trace - see screenshot here :
http://www.glimmer.adsl24.co.uk/images/Dolphin-20120910.png

At first I assumed that - in the usual way - I needed to install Dolphin debug
symbols to get a useful stack trace ... I'd already told the crash handler I
could say what I was doing prior to the crash, and that I'd noticed strange
behaviour beforehand ...

But then I discovered I apparently already have the Dolphin debug symbols
installed :

http://packages.debian.org/squeeze/amd64/kdebase-dbg/filelist :
Filelist of package kdebase-dbg in squeeze of architecture amd64
/usr/lib/debug/usr/bin/dolphin
/usr/lib/debug/usr/bin/kappfinder
/usr/lib/debug/usr/bin/kbookmarkmerger
/usr/lib/debug/usr/bin/kdepasswd
etc., etc.

State of my system :
nick@mybox:~$ apt-cache policy kdebase-dbg
kdebase-dbg:
Installed: 4:4.4.5-2
Candidate: 4:4.4.5-2
Version table:
*** 4:4.4.5-2 0
500 http://ftp.uk.debian.org/debian/ squeeze/main amd64 Packages
100 /var/lib/dpkg/status

Can anyone help me figure out how to proceed in order to get useful crash dumps
from Dolphin ?
Is there some other package (perhaps called by Dolphin) that needs debugging
here ?

Thanks,
Nick
--
Never FDISK after midnight


--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120911211...@glimmer.adsl24.co.uk

[Nick Boyce]

On Tuesday 11 Sep 2012 21:13:15 Nick Boyce wrote:

> Can anyone help me figure out how to proceed in order to get useful crash
> dumps from Dolphin ?

It's been suggested to me off-list that if I posted the entire backtrace it
might help someone see which debug symbols I need, so I've attached it here as
a textfile (it seems strangely short).

> Is there some other package (perhaps called by Dolphin) that needs
> debugging here ?

Actually (answering my own question), looking at just the first 4 stack frames
... I could use my superpowers to deduce perhaps the missing debug symbols are
the ones for D-Bus :-)

Would I be right ?

===================< cut >====================
Application: Dolphin (dolphin), signal: Segmentation fault
The current source language is "auto; currently asm".
[KCrash Handler]
#5 0x00007f801bfaf324 in ?? () from /lib/libdbus-1.so.3
#6 0x00007f801bfc0d8d in ?? () from /lib/libdbus-1.so.3
#7 0x00007f801bfb2cde in ?? () from /lib/libdbus-1.so.3
#8 0x00007f8021446107 in q_dbus_timeout_handle (this=0x919210,
e=0x7fffa06a9cb0) at qdbus_symbols_p.h:172
===================< cut >====================

Would that be package 'dbus-1-dbg' ?
http://packages.debian.org/squeeze/dbus-1-dbg

[What's the "-1-" bit of the name signify ?]

Cheers,
Nick
--
"When fascism comes to America, it will be wrapped in a flag and carrying
a cross." -- Sinclair Lewis, 1935

[Martin Steigerwald]

Hi Nick,

Am Mittwoch, 12. September 2012 schrieb Nick Boyce:
> On Tuesday 11 Sep 2012 21:13:15 Nick Boyce wrote:
> > Can anyone help me figure out how to proceed in order to get useful
> > crash dumps from Dolphin ?
>
> It's been suggested to me off-list that if I posted the entire
> backtrace it might help someone see which debug symbols I need, so
> I've attached it here as a textfile (it seems strangely short).
>
> > Is there some other package (perhaps called by Dolphin) that needs
> > debugging here ?
>
> Actually (answering my own question), looking at just the first 4 stack
> frames ... I could use my superpowers to deduce perhaps the missing
> debug symbols are the ones for D-Bus :-)
>
> Would I be right ?

Yes. You used the force and the force was with you ;)

> ===================< cut >====================
> Application: Dolphin (dolphin), signal: Segmentation fault
> The current source language is "auto; currently asm".
> [KCrash Handler]
> #5 0x00007f801bfaf324 in ?? () from /lib/libdbus-1.so.3
> #6 0x00007f801bfc0d8d in ?? () from /lib/libdbus-1.so.3
> #7 0x00007f801bfb2cde in ?? () from /lib/libdbus-1.so.3

mondschein:~> dpkg -S /lib/libdbus-1.so.3
libdbus-1-3: /lib/libdbus-1.so.3

> #8 0x00007f8021446107 in q_dbus_timeout_handle (this=0x919210,
> e=0x7fffa06a9cb0) at qdbus_symbols_p.h:172
> ===================< cut >====================
>
> Would that be package 'dbus-1-dbg' ?
> http://packages.debian.org/squeeze/dbus-1-dbg

mondschein:~> apt-cache search dbus dbg
libdbus-glib-1-2-dbg - simple interprocess messaging system (GLib library debug symbols)
python-dbus-dbg - Debug build of the D-Bus Python interface
dbus-1-dbg - simple interprocess messaging system (debug symbols)
python-qt4-dbus-dbg - DBus Support for PyQt4 (debug extensions)

So yes.

> [What's the "-1-" bit of the name signify ?]

Don´t know.


Similar it goes for others like:

#19 0x00007f801b4d96f2 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#20 0x00007f801b4dd568 in ?? () from /lib/libglib-2.0.so.0
#21 0x00007f801b4dd71c in g_main_context_iteration () from /lib/libglib-2.0.so.0

But then this one does already seem installed its just that particular
address that gdb can´t resolve.

You can do this with almost all references in there. Sometimes are is a
bigger metapackage like kdelibs5-dbg which might include dbg symbols
for libs in other packages (didn´t verify whether thats exactly the case
with kdelibs5-dbg).

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7

--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/201209121432...@lichtvoll.de

[Nick Boyce]

On Wednesday 12 Sep 2012 13:32:48 Martin Steigerwald wrote:

> > Actually (answering my own question), looking at just the first 4 stack
> > frames ... I could use my superpowers to deduce perhaps the missing
> > debug symbols are the ones for D-Bus :-)
> >
> > Would I be right ?
>
> Yes. You used the force and the force was with you ;)

Thanks for the confirmation :)
I've installed 'dbus-1-dbg', but experienced no more Dolphin crashes yet.

> Similar it goes for others like:
>
> #19 0x00007f801b4d96f2 in g_main_context_dispatch () from
> /lib/libglib-2.0.so.0 #20 0x00007f801b4dd568 in ?? () from
> /lib/libglib-2.0.so.0
> #21 0x00007f801b4dd71c in g_main_context_iteration () from
> /lib/libglib-2.0.so.0
>
> But then this one does already seem installed its just that particular
> address that gdb can´t resolve.
>
> You can do this with almost all references in there.

[snip]

Thanks for the explanation - I think I'm beginning to get the hang of it now,
though would very much like to understand how some function names can remain
unresolvable while others in the same package (libglib in this instance) are
not. Maybe they're private functions of some sort, or maybe the compiler can
be told that some names are of no interest. I guess I'll understand better by
writing a KDE program or two

Cheers,
Nick
--
Just don't create a file called -rf. :-)
~~ Larry Wall in<11...@jpl-devvax.JPL.NASA.GOV>

--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120918034...@glimmer.adsl24.co.uk

[Martin Steigerwald]

Am Dienstag, 18. September 2012 schrieb Nick Boyce:
> > Similar it goes for others like:
> >
> >
> > #19 0x00007f801b4d96f2 in g_main_context_dispatch () from
> > /lib/libglib-2.0.so.0 #20 0x00007f801b4dd568 in ?? () from
> > /lib/libglib-2.0.so.0
> > #21 0x00007f801b4dd71c in g_main_context_iteration () from
> > /lib/libglib-2.0.so.0
> >
> >
> >
> > But then this one does already seem installed its just that
> > particular address that gdb can´t resolve.
> >
> >
> >
> > You can do this with almost all references in there.
>
> [snip]
>
> Thanks for the explanation - I think I'm beginning to get the hang of
> it now, though would very much like to understand how some function
> names can remain unresolvable while others in the same package
> (libglib in this instance) are not. Maybe they're private functions of
> some sort, or maybe the compiler can be told that some names are of no
> interest. I guess I'll understand better by writing a KDE program or
> two

I have no idea about this one either.

Cheers,

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7

--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/201209181107...@lichtvoll.de

[Lisandro Damián Nicanor Pérez Meyer]

On Mon 17 Sep 2012 23:45:26 Nick Boyce escribió:
[snip]
> Thanks for the explanation - I think I'm beginning to get the hang of it
> now, though would very much like to understand how some function names can
> remain unresolvable while others in the same package (libglib in this
> instance) are not. Maybe they're private functions of some sort, or maybe
> the compiler can be told that some names are of no interest. I guess I'll
> understand better by writing a KDE program or two

Normally just missing dbg packages. And it's not directly related to KDE
programs but to compiled apps (well, at least in C and C++).

Kinds regards, Lisandro.

--
Primero te ignorarán, luego se reirán,
luego te combatirán, luego ganarás.
Mahatma Gandhi

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/