|
|
| (73 intermediate revisions by 27 users not shown) |
| Line 1: |
Line 1: |
| ==How to create useful crash reports==
| | {{Moved To Community | Guidelines_and_HOWTOs/Debugging }} |
| | |
| A good crash report at [http://bugs.kde.org 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 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 but be useful for the developer, so just write it down.
| |
| | |
| ===Backtraces===
| |
| | |
| Backtraces are essential as well. They may look meaningless to you, actually they could contain a wealth of useful information. A backtrace describes which functions were called prior to the backtrace, 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)
| |
| (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)
| |
| (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)
| |
| (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)
| |
| (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)
| |
| (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)
| |
| (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:
| |
| | |
| *'''Compiling KDE from sources''' - At the configure stage, you should supply the parameter <tt>--enable-debug=full</tt> in order to build debug symbols in the resulting files. Then just <tt>make</tt> and <tt>make install</tt> like you're used to.
| |
| *'''Kubuntu/Ubuntu''' - The Ubuntu family makes things quite easy. Every official KDE module has an additional package in the repository, suffixed with <tt>-dbg</tt>. Always install <tt>kdelibs-dbg</tt>, because all KDE applications use kdelibs. Then you should install a -dbg package for the application which crashed. For example if KOrganizer crashed you should install <tt>kdepim-dbg</tt> as well.
| |
| *'''Gentoo''' - Gentoo has it's [http://www.gentoo.org/proj/en/qa/backtraces.xml own document] describing how to proceed.
| |
| *'''openSUSE''' - openSUSE offers a separate repository for downloading debug enabled packages. Look at the [http://en.opensuse.org/Package_Repositories package repository page] for the most recent URL.
| |
| <!--*'''Fedora'''
| |
| *'''Mandriva''' - ???-->
| |
| *'''FreeBSD ports''' - Please refer to the [http://freebsd.kde.org/faq.php#AKDEapplicationcrashedandIwanttofileabugreportathttpbugskdeorgbutthebacktraceintheKDECrashManagerisuselessWhatcanIdo KDE on FreeBSD FAQ].
| |
| | |
| Now just make your application crash. The KDE Crash Dialog should appear <!-- IMAGE -->, which has 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:
| |
| | |
| Good backtrace here
| |
| | |
| ===Retrieving a backtrace with GDB===
| |
| | |
| 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 <tt>gdb</tt>, the GNU Debugger.
| |
| | |
| 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 <tt>run</tt> command:
| |
| | |
| (gdb) run
| |
| | |
| 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:
| |
| | |
| (gdb) backtrace
| |
| | |
| 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.
| |
