There are a lot of ways of identifying duplicate reports depending on the kind of bug.
|You can search in different products at the same time|
|Due to the heavy usage of libraries in the KDE software, a bug reported for an application may be tracked in a library product (example, a bug in Plasma Desktop may be a bug in kdelibs and therefore tracked in the "kdelibs" product)|
|When using more than one word in the "Comments" field you need to select the option "contains all of the words/strings"|
|It is sometimes difficult to choose the proper ones, as the way of describing a scene varies from person to person|
Perform a full search over the same product, initially in the "general" component, putting the "ClassName::FunctionName" pairs that identify the crash in the Comments field of the form (if you put more than one pair, you need to select the option "contains all of the words/strings")
This bug looks related to bug XXXXXX
(XXXXXX being the bug ID of "master")
|You may find related reports that are already marked as duplicate of a third report. Always try to use this third report as the main one (resolve the duplicates chain). However, in some cases, the main report refers to a root issue and some of its duplicates may refer to sub-issues. In those cases try to check which one refers to the issue you are looking at.|
A backtrace is a piece of information that describes what the application was doing when it encountered an error and had to close itself. It is a “function stack” leading to the “crashing point”.
In KDE applications, the backtraces are generated by the Crash Handler Dialog (“DrKonqi”). They can also be generated by the general debugger “GDB”, but that involves more steps.
The backtrace is read from top to bottom. The first line shows where the crash occurred (because of an illegal instruction, invalid pointer, memory problem or other issue). The other lines show the "way to the first function".
Application: Plasma Workspace (kdeinit4), signal: Bus error [KCrash Handler] #5 0x00007fb563bb8f02 in KPixmapCache::Private::mmapFile (this=0x92df60, filename=..., info=0x92dfb0, newsize=33656832) at /usr/src/debug/kdelibs- 4.4.1/kdeui/util/kpixmapcache.cpp:491 #6 0x00007fb563be3c34 in KPixmapCache::Private::mmapFiles (this=0x92df60) at /usr/src/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:419 #7 0x00007fb563be38e3 in KPixmapCache::Private::init (this=0x92df60) at /usr/src/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1061 #8 0x00007fb563be576d in KPixmapCache::discard (this=0x1203ca0) at /usr/src /debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1279 #9 0x00007fb563be5e48 in KPixmapCache::deleteCache (name=...) at /usr/src /debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1255 #10 0x00007fb55afdc97d in Plasma::ThemePrivate::discardCache (this=0x7a7d30) at /usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:224 #11 0x00007fb55afe009b in Plasma::ThemePrivate::setThemeName (this=0x7a7d30, tempThemeName=<value optimized out>, writeSettings=<value optimized out>) at /usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:380 #12 0x00007fb55afe19fb in Plasma::Theme::settingsChanged (this=0x70af20) at /usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:341 #13 0x00007fb55afe2918 in Plasma::ThemePrivate::settingsFileChanged (this=0x7a7d30, file=<value optimized out>) at /usr/src/debug/kdelibs- 4.4.1/plasma/theme.cpp:335 ...
#NumberInTheStack MemoryAddress in Namespace::Class:FunctionMember (argumentThis=pointerValue, argument1=value, argument2=value, ...) at path/to /source/code/file.cpp:linenumber
#13 0xb759d5d7 in Nepomuk::ResourceData::determineUri (this=0x91ec5f8) at /home/kde-devel/kde/src/KDE/kdelibs/nepomuk/core/resourcedata.cpp:671
The first thing you need to do is to locate where it crashed, identifying the "[KCrash Handler]" mark (only in backtraces fetched using DrKonqi).
If the application only had one thread, then it is at the top of the unique thread. Otherwise you may need to look at all the threads (the KCrash mark may not always be in the Thread number 1).
Once you located the "crashing thread start", pick up the first two or three "ClassName::Functions" pairs from top to bottom (some functions should be ignored, read below).
These pairs will be used as "keywords" for the duplicate search.
|This is only a general rule. There are some special cases when the first three functions at the top may be the same but the crash may be different (especially in complex application/libraries such as Konqueror)|
If the first backtrace functions are not available (they are not there, or there are "??") then we cannot proceed without asking for more information (a more complete backtrace).
Some functions or calls are common to a lot of applications using the same core libraries (like the Qt library, glib, glibc, or many others). These kinds of functions should not be used for searching as they are not representative of the crash itself and the search may return lots of results.
Classes and functions to ignore in a backtrace:
There are special crashes related to the X11 graphics server. To identify these crashes you can search for the "XIOError" function name (often on Thread 1). The "[KCrash handler]" mark appears in a secondary thread.
The important thing in identifying these crashes is recognizing the functions below the XIOError call (which functions caused the X11 error).
In most of these crashes the functions below "[KCrash handler]" are not important (but they could still be useful to search for duplicates).
For every KDE application it is recommended to install the debug information for "kdelibs" and "qt4"
|kdebase (KDE base applications)||kdebase-dbg, kdebase-runtime-dbg, kdebase-workspace-dbg||kdebase4-debuginfo, kdebase4-runtime-debuginfo, kdebase4-workspace-debuginfo||kdebase-debuginfo, kdebase-runtime-debuginfo, kdebase-workspace-debuginfo||kdebase4-debug, kdebase4-runtime-debug, kdebase4-workspace-debug|
|General example for every KDE "MODULE"||kdeMODULE-dbg||kdeMODULE4-debuginfo||kdeMODULE-debuginfo||kdeMODULE4-debug|
|Phonon (multimedia subsystem)||phonon-dbg||libphonon4-debuginfo / phonon4-debuginfo||phonon-debuginfo||phonon-debug|
For a detailed list of distribution naming scheme examples you can look at How to obtain debug packages for every distribution.