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, are quite likely to crash at some point. These crashes are a lot easier to fix if the Developers know what is causing it. Enter debugging.
Contents |
Preparing For Debugging
Compiling from source
In order to get full use out of gdb, you need to tell CMake to include debugging information in the build. When running cmake, include the flag -DCMAKE_BUILD_TYPE=debugfull, as in:
cmake $SRCDIR -DCMAKE_INSTALL_PREFIX=$KDEDIR -DCMAKE_BUILD_TYPE=debugfull
If you have not compiled kdelibs yourself like this, you should install the debug packages for kdelibs provided by your distribution (see below).
Using distribution packages
If you are using your distribution's binary packages, they will often provide debugging information in a separate package. For example, if Amarok is contained in the amarok package, there is usually an amarok-debug or amarok-dbg package, which you should install.
In addition to Amarok's debug packages, you should install the kdelibs and possibly the Qt debug packages (most likely kdelibs-debug or kdelibs-dbg and qt-debug, qt4-debug, qt-dbg or qt4-dbg).
These packages may be contained in a separate repository that is not enabled by default. See your distribution's documentation for more information.
Installing these packages will not slow Amarok down in any way. They will not have any effect until you actually try to debug Amarok in gdb, when they will turn the backtrace from a useless string of text and numbers into something developers can use to find and fix the problem.
Gentoo
If installing from ebuild, do the following
mkdir -p /etc/portage echo "media-sound/amarok debug" >> /etc/portage/package.use FEATURES="nostrip" emerge media-sound/amarok
Also make sure the CFLAGS are reasonable and do not have -fomit-frame-pointer.
For the best backtraces, you should set similar USE flags (as well as the nostrip option) for kdelibs and Qt 4.
Debug Output
When Amarok is built in debug mode (see above), it can produce a lot of console output about what it is doing. This can be useful for tracking down errors, but it slows Amarok down significantly so is disabled by default.
If a developer asks you for debugging output, you should quit Amarok completely (Quit on the Amarok menu, or right-click the tray icon and choose Quit), then run the following in a terminal:
amarok --debug
Your terminal will get flooded with debugging output. Reproduce the problem, then copy the last 50 or so lines (or however much the developer asks for) from the terminal into a text file, which you should attach to the bug report.
Note: simply installing your distribution's *-debug packages will NOT allow you to get debugging output of this form. However, it will allow you produce useful backtraces (see below).
Getting a backtrace
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:
yum install gdb
Mandriva:
urpmi gdb
Debian/Ubuntu:
apt-get install gdb
Gentoo:
emerge gdb
OpenSUSE:
zypper in gdb
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.
gdb amarok
(In Amarok 2, there is no separate amarokapp binary any more, so you can debug against amarok directly.)
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 in a terminal when Amarok hangs:
gdb `which amarok` -p `pidof amarok` (gdb) thread apply all bt
You will then get a backtrace, which you should submit in your bug report.