Amarok Website

From Amarok Wiki

Normally, programs are expected to run correctly. They have gone through betas, and been tested by many people. These release versions rarely need debugging. On the other hand versions released in beta, along with versions taken straight from SVN, have a chance, and most likely will at some point or another, crash. These crashes are a lot easier to fix if the Developers know what is causing it. Enter debugging.

Contents 1 Howto 1.1 Preparing For Debugging 1.2 GDB 1.3 Debugging an already running instance of Amarok

Howto

Preparing For Debugging

In order to get full use out of gdb, you need to append a few flags to your amarok configure script.

This will provide useful output.

Note: Gentoo users, if installing from ebuild, do the following

Also make sure the CFLAGS are reasonable and do not have -fomit-frame-pointer.

GDB

((Add instructions for other debbuger's? Are There Any Others?))

GDB is GNU's Debugger. It is useful for providing backtraces, which are essentially a list of things that the program tried to do before the crash. Chances are one of these caused the crash.

GDB is prepackaged for many distros.
Redhat:

Mandrake:

Debian/Ubuntu:

Gentoo:

You can also compile GDB from source. GDB can be obtained from GDB Home Page Compile and install as you would any other program. Now Run it.

Note: amarok requires you to gdb against amarokapp, not amarok.

You should see some info like this

Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
(gdb)                          

at the gdb prompt type:

(gdb) run

Now do whatever you did that originally caused amarok to crash. Now when it crashes however, gdb will freeze it, not crash it. Go back to the console you ran gdb from, and type

(gdb) bt

Output such as the following should be seen. Note that it references specific functions, files and line numbers. If instead there are many ????'s, then the backtrace is most likely worthless.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1236346144 (LWP 1654)]
0xb6f6179b in QString::latin1ToUnicode () from /usr/lib/libqt-mt.so.3
(gdb) bt
#0  0xb6f6179b in QString::latin1ToUnicode () from /usr/lib/libqt-mt.so.3
#1  0xb6f62056 in QString::QString () from /usr/lib/libqt-mt.so.3
#2  0xb50adb6a in HelixConfigDialog (this=0x881aea8, engine=0x86924a8, p=0x0) at helix-configdialog.cpp:215
#3  0xb50a7acc in HelixEngine::configure (this=0x86924a8) at helix-engine.cpp:96
#4  0x080c0177 in AmarokConfigDialog::soundSystemChanged (this=0x88a3660) at configdialog.cpp:307
#5  0x080bfe34 in AmarokConfigDialog::updateWidgets (this=0x88a3660) at configdialog.cpp:235
#6  0xb7684399 in KConfigDialog::show () from /usr/lib/libkdeui.so.4
#7  0x0808f051 in App::slotConfigAmarok (this=0xbffff960, page=@0xbfffed20) at app.cpp:788
#8  0x0808fc0d in App::qt_invoke (this=0xbffff960, _id=20, _o=0xbfffedb0) at app.moc:108
#9  0xb6cae067 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#10 0xb6cadeae in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#11 0xb754d88b in KAction::activated () from /usr/lib/libkdeui.so.4
#12 0xb754cffa in KAction::slotActivated () from /usr/lib/libkdeui.so.4
#13 0xb754d2be in KAction::slotButtonClicked () from /usr/lib/libkdeui.so.4
#14 0xb754dba1 in KAction::qt_invoke () from /usr/lib/libkdeui.so.4
#15 0xb6cae067 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#16 0xb75f7bc5 in KToolBarButton::buttonClicked () from /usr/lib/libkdeui.so.4
#17 0xb75f63ba in KToolBarButton::mouseReleaseEvent () from /usr/lib/libkdeui.so.4
#18 0xb6ce17e9 in QWidget::event () from /usr/lib/libqt-mt.so.3
#19 0xb6c56370 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3
#20 0xb6c55ac7 in QApplication::notify () from /usr/lib/libqt-mt.so.3
#21 0xb7270ab5 in KApplication::notify () from /usr/lib/libkdecore.so.4
#22 0xb6bef12f in QETWidget::translateMouseEvent () from /usr/lib/libqt-mt.so.3
#23 0xb6bece1c in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3
#24 0xb6c02ec2 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
#25 0xb6c6774c in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#26 0xb6c6760e in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
#27 0xb6c5657b in QApplication::exec () from /usr/lib/libqt-mt.so.3
#28 0x081a6e55 in main (argc=1, argv=0xbffffae4) at main.cpp:92
(gdb)

This output should be what is attached to any bugreport.

Debugging an already running instance of Amarok

Sometimes we can't necessary reproduce bugs that easily, and it is easier to simply debug when it hangs initially. To do this, try the following

Amarok hangs...

open terminal...

gdb `which amarokapp` -p `pidof amarokapp`

(gdb) thread apply all bt

[output comes]

submit this as your bug report.