This document describes how to create useful bug reports for crashes of KDE applications.
How to create useful crash reports
A good crash report consists of two parts: a description of how to reproduce the crash and a backtrace of the crash. With any of those elements missing, it is very hard (if not impossible) for developers to tackle the problem.
A description should describe everything that you were doing prior to the crash. It should not just say "it crashed". Did you click on a button, did you open a particular website or file which caused problems? These little details, which may look useless to you, may be useful for the developers, so just write them down.
- The KDE version is an important detail that is often missing in bug reports.
If you do not know what KDE version are you using, you can get it by selecting the "About KDE" option in the Help menu of every KDE application, or by running the command kde4-config --version in Konsole. You will get an output like this:
Qt: 4.5.3 KDE: 4.3.2 (KDE 4.3.2) kde4-config: 1.0
A more insightful article on how to write good bug descriptions is available at this link, please read that before reporting bugs.
Application specific details
For several applications it can be useful to have specific details inside the bug reports:
- Plasma Desktop: Plasmoids you have in your desktop (both official and unofficial), desktop settings (wallpaper plugin, themes), activities and dashboard configuration.
- KWin (the windows manager): state of compositing(desktop effects): enabled / suspended / disabled, kind of effects enabled, window decoration.
- Konqueror: Sites you were visiting, number of opened tabs, plugins you have installed, non-default settings.
- Dolphin: file view mode, grouping and sorting settings, preview settings, directory you were browsing.
- Kopete: IM protocols you use, plugins you use.
- KMail: Mail protocols and account-types you use.
- KWrite/Kate/KOffice: Type of the document you were editing.
- Juk/Dragon/Amarok (multimedia players): Type of media (extension and format) you were watching and/or listening to.
Backtraces are essential. They may look meaningless to you, but they might actually contain a wealth of useful information. A backtrace basically describes what was happening inside the application when it crashed, in a way that developers may track down where the mess started.
- 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 can not be searched.
Even though pasting backtraces directly is preferred 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.