(→How to create useful crash reports: Add great link on general bug reporting)
|Line 23:||Line 23:|
Backtraces are essential
Backtraces are essential. They may look meaningless to you, they contain a wealth of useful information. A backtrace describes which functions were called prior to the crash, so that developers may track down in which function the mess started. Having good backtraces has a downside: libraries and executables occupy much more disk space than their optimized counter parts. That's the reason why many distros choose to install stripped files, which results in useless backtraces:
(no debugging symbols found)
(no debugging symbols found)
Languages: عربي | Asturianu | Català | Česky | Kaszëbsczi | Dansk | Deutsch | English | Esperanto | Español | Eesti | فارسی | Suomi | Français | Galego | Italiano | 日本語 | 한국어 | Norwegian | Polski | Português Brasileiro | Română | Русский | Svenska | Slovenčina | Slovenščina | српски | Türkçe | Tiếng Việt | Українська | 简体中文 | 繁體中文
This document describes how to reproduce a useful backtrace of crashing KDE applications. First, some general information is given. Then, we will describe for several distributions how to prepare your KDE packages and gaining the backtrace. This should be enough for most people. There are additional sections on how to create backtraces with the GNU Debugger and with Valgrind, which are in some cases useful.
A good crash report at Bugzilla consists of two parts: a description of how to reproduce the crash and a backtrace of the crash. With one of those elements missing, it is much harder (if not impossible) for developers to tackle the problem.
A description should consist of more than only "it crashed". Try to describe everything you did prior to the crash. Did you click on a button, opened a particular website or file which caused problems? That little detail which may look useless to you may be useful for the developer, so just write it down.
A more insightful article on how to write good bug descriptions is available at this link, please read that before reporting bugs.
Don't attach the backtrace to the bug report. Instead, simply paste it. This way it is much easier for developers to search for duplicate reports, because attachments will not be searched.
If you paste a backtrace to a report, make sure you strip all but one or two of the
(no debugging symbols found)
lines from the backtrace as they make it harder too read.
Even though pasting backtraces directly is prefered over adding an attachment, please do not paste other things like logs (valgrind, strace or terminal output) or example data (mails, HTML files and so on). Use attachments for these items.
Backtraces are essential. They may look meaningless to you, but they might actually contain a wealth of useful information. A backtrace describes which functions were called prior to the crash, so that developers may track down in which function the mess started. Having good backtraces has a downside: libraries and executables occupy much more disk space than their optimized counter parts. That's the reason why many distros choose to install stripped files, which results in useless backtraces:
(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1233848624 (LWP 12212)] [New Thread -1255081072 (LWP 12820)] [New Thread -1240921200 (LWP 12819)] [New Thread -1266680944 (LWP 12818)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0xffffe410 in __kernel_vsyscall () #0 0xffffe410 in __kernel_vsyscall () #1 0xb6a1210b in ?? () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb6a85afe in ?? () from /usr/lib/libX11.so.6 #3 0x00000003 in ?? () #4 0x082149c0 in ?? () #5 0x00003ffc in ?? () #6 0x00000000 in ?? ()
But no worries, with some modifications you can create full blown backtraces for KDE applications.
If your distribution has debugging-enabled packages, install them. Here's a list of how to do it for some distributions:
If your distribution doesn't have debugging-enabled packages for KDE, you'll have to compile KDE from sources:
Then it's just make and make install as you're used to.
Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab.
Click that tab and wait for a minute. This process may take quite some memory, so things may go sluggish all of a sudden. But the result should look much better. For example:
Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1232783168 (LWP 7604)] [KCrash handler] #6 0x0806be76 in TreeMapItem::parent (this=0x0) at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.h:285 #7 0x08065fea in TreeMapItemList::compareItems (this=0xbfec04a8, item1=0x0, item2=0x0) at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:720 #8 0xb7281619 in QGList::operator== () from /usr/qt/3/lib/libqt-mt.so.3 #9 0x0806d498 in QPtrList<TreeMapItem>::operator== (this=0xbfec04a8, list=@0xbfec0468) at /usr/qt/3/include/qptrlist.h:74 #10 0x08062e18 in TreeMapWidget::mousePressEvent (this=0xbfec03ac, e=0xbfebff1c) at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/treemap.cpp:1840 #11 0xb7004a63 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3 #12 0xb6f6bca7 in QApplication::internalNotify () from /usr/qt/3/lib/libqt-mt.so.3 #13 0xb6f6ca88 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3 #14 0xb7725a84 in KApplication::notify (this=0xbfec055c, receiver=0xbfec03ac, event=0xbfebff1c) at /home/bram/KDE/kde3/kdelibs/kdecore/kapplication.cpp:550 #15 0xb6f0bfd2 in QETWidget::translateMouseEvent () from /usr/qt/3/lib/libqt-mt.so.3 #16 0xb6f0b8b0 in QApplication::x11ProcessEvent () from /usr/qt/3/lib/libqt-mt.so.3 #17 0xb6f1b761 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3 #18 0xb6f82831 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3 #19 0xb6f826b6 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3 #20 0xb6f6b72f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3 #21 0x0805181e in main (argc=134673960, argv=0xffffffff) at /home/bram/KDE/kde3/kdeaddons/konq-plugins/fsview/main.cpp:55
This looks better, right? It shows memory addresses, the source files and line numbers and the parameters passed to functions. Which make it more helpful to the developer where to look for the problem.
|You need GDB installed to get the backtrace of a crash. Please read the next section to know what GDB is, and how to install it.|
In some cases, it is not possible to create a backtrace with the KDE Crash Dialog. This may be caused by an application which entered an infinite loop, or the crash dialog did not appear at all for some reason. You can try to grab a backtrace with gdb, the GNU Debugger. GDB is widely available through distribution packages.
Invoking GDB differs from the situation. You can run an application from inside gdb, or attach gdb to an already running process. The latter may be useful when an application already has entered an infinite loop. But we will first start with running an application inside gdb. From the shell, run:
$ gdb someKDEapp
The GDB prompt will appear. Note that this does not start the application itself, you should run it by invoking the run command:
This will run the application like you are used to, and you can work with it like normal (it only consumes far more memory and may feel sluggish). Now it's time to reproduce your crash. When you succeed, the application just closes and you should return to your GDB prompt. Now it's time to run the 'backtrace' command:
|Some KDE applications (such as JuK and KTorrent) have special code to ensure that there is only one running instance of the application at a time. For these applications you should type in "run --nofork" at the (gdb) prompt instead of "run" because otherwise gdb will try to debug the wrong process. If you are unsure as to whether to use --nofork just try it. If the application says it's an unknown option you can remove --nofork.|
This should give a good backtrace which can be posted at the KDE Bugzilla.
In case you want to attach to an existing process, run the following command in the shell:
$ gdb someKDEapp pid
where pid is the process ID of the process you want to attach to. Once attached, and the process is in an infinite loop, force it to crash with the following command:
$ kill -SEGV pid
Of course, replace the pid of the application (not the gdb instance!). When you run the 'backtrace' command again, a useful backtrace will appear.
When it comes to crashes, Valgrind is also a useful tool to create a backtrace. It's not a substitution for GDB, but rather a supplement.
When you run an application in valgrind, every piece of memory read or written by the application is being checked. Valgrind will report erroneous memory operations in the standard output or in a log file. Since most crashes are due to an invalid memory read, valgrind can be useful to track down where the problem occurs.
|Valgrind consists of several tools in order to check or profile an application. For this article, we only use memcheck, the default tool when valgrind is being invoked.|
Like GDB, Valgrind makes running an application much slower, while consuming a lot more resources.
Start the application within valgrind:
$ valgrind --log-file=someKDEapp someKDEapp
Now reproduce the crash. As soon as this happens, the application and valgrind will terminate. What's left is a file named someKDEapp.pid where pid is replaced by the process ID of the valgrind process. The file may list more errors than the one causing the crash. Here's the bit causing the crash which corresponds to the GDB backtrace above:
==23292== Invalid read of size 4 ==23292== at 0x806BD9E: TreeMapItem::parent() const (treemap.h:285) ==23292== by 0x8065FB9: TreeMapItemList::compareItems(void*, void*) (treemap.cpp:720) ==23292== by 0x50AC618: QGList::operator==(QGList const&) const (in /usr/qt/3/lib/libqt-mt.so.3.3.8) ==23292== by 0x806D3BF: QPtrList<TreeMapItem>::operator==(QPtrList<TreeMapItem> const&) const (qptrlist.h:74) ==23292== by 0x8062DE7: TreeMapWidget::mousePressEvent(QMouseEvent*) (treemap.cpp:1840) ==23292== by 0x4E2FA62: QWidget::event(QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8) ==23292== by 0x4D96CA6: QApplication::internalNotify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8) ==23292== by 0x4D97A87: QApplication::notify(QObject*, QEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8) ==23292== by 0x4809AC3: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550) ==23292== by 0x4D36FD1: QETWidget::translateMouseEvent(_XEvent const*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8) ==23292== by 0x4D368AF: QApplication::x11ProcessEvent(_XEvent*) (in /usr/qt/3/lib/libqt-mt.so.3.3.8) ==23292== by 0x4D46760: QEventLoop::processEvents(unsigned) (in /usr/qt/3/lib/libqt-mt.so.3.3.8) ==23292== Address 0x2C is not stack'd, malloc'd or (recently) free'd
But to be sure, just attach the whole log file to the crash report.