Initial version by Dario Andres (2010-03/2010-04).
Initial corrections by Lydia Pintscher (Nightrose)
This "ultimate" guide is based on my own experience (approximately 2 years) on the KDE bug tracker.
I hope it works for you too :)
If you are not familiar with the Bugzilla (KDE bug tracker system) interface, you may find this guide useful: Quick Introduction to Bugzilla
You may want to properly setup your bugzilla account as mentioned at Configure your account
Manpower is always needed in a bug tracker, but as any action taken on it may be potentially destructive to other people's work; or it may end up messing things up (and consuming the developers' or other triager's time) the tracker requires special permissions to perform changes in bug reports.
If you want to work in the bug tracker you need to prove that you know what you are doing.
Initially you will ask for support on #kde-bugs (on IRC) and add comments in the bug report (so other people will see and check them, perform the needed actions, and evaluate your work)
You could use different techniques or approaches to triage the reports according to your current mood or the amount of work you want to do for example.
|The two following techniques are complementary.|
In this technique you check all the bug reports (of all the products) which were filed today (or some days ago).
You can focus on crash, normal or wish reports individually (recommended) or all of them together.
Not so Good:
This technique could be used every week (or every day)
Choose a product (application or library). Then choose a period of time like 1 month or 1 or 2 years (or "from the beginning of the current year", or even from the very beggining (like 2000)). You can also choose which kind of reports you want to handle.
This technique is useful to audit old bugs or perform a deep clean (in case that the bugs weren't triaged on a daily basis previously).
Not so Good:
You can also filter out results (and be even more focused) if you select a custom component inside the product (a subsection of the application).
This technique could be used two times a month.
Now that you have a list of bug reports, pick one and start working.
There are several things that must be checked and "fixed" to make an initial bug report an interesting and useful piece of information for the developers to check.
|if at any point you don't really know how to continue, because you don't understand the issue properly, always ask to the developers or related contributors|
As KDE has too many users, we get a lot of reports about bugs which are already reported (the so named "duplicates"). Before putting any effort in the current report we should check for the main report.
There are a lot of ways of identifying duplicate reports depending of the kind of bug.
|You can search on 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 being tracked at a library product (example, a bug in Plasma Desktop may be a bug in kdelibs, and therefore being 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 (but we have time)|
Perform a full search over the same product (read general note), initially on 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 found 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" reports 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 was the application doing when it encountered the 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 issues). 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 thread (the KCrash mark may not be always in the Thread number 1)
Once that you located the "crashing thread start", pickup the first two or three "ClassName::Functions" pairs from top to bottom (some functions should be ignored, read below)
This 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 function at the top may be the same but the crash may be different (specially on complex application/libraries as Konqueror)|
If the first backtrace functions aren't available (they are not there, or there are "??") then we can't 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). This kind of functions should not be used for search as they are not representative of the crash itself and it 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 this crashes you can search for the "XIOError" function name (often on Thread 1). The "[KCrash handler]" mark appears in a secondary thread.
The important things to identify those crashes is recognizing the functions *below* the XIOError call (this is, which functions caused the X11 error).
In most of this crashes the functions below "[KCrash handler]" are not important (but they could still be useful to search for duplicates).
Check if the bug is caused by an external plugin/add-on or distribution issue
There are several bugs which may be caused by external add-ons. If you are sure this is the case, you should dismiss the report, telling the reporter to file a new bug in a different place.
Distributions can also bring some trouble, specially with packaging.
Some problems that may cause bugs are:
Also, distribution can include their own add-ons (to bring their own branding or any other special function). If you know KDE software enough you may be able to recognize these unofficial add-ons.
If the reporter mentions an application or dialog you cannot identify, you could try requesting a screenshot; other people may identify if it is a KDE application or an external addition.
|The UPSTREAM resolution refers to bugs caused by libraries/dependencies, upstream in the software stack (like Qt, glibc, X11). The DOWNSTREAM resolution refers to bug caused by the Distributions (broken packaging, ...) or by external plugins (unofficial Plasma widgets, other extensions, ...)|
Now that you know that the bug report is unique, and that is not an external issue, you need to check all the needed information is there.
If you can reproduce the crash at will (or you experience this regularly), can you install the "PACKAGENAME" package and post a complete backtrace here? (you can get more information at http://techbase.kde.org/User:DarioAndres /Basic_Guide_about_Crash_Reporting ) Thanks
The names of the missing packages depends of the application and the distribution (as package naming scheme changes..). Look at List of debug package names on several Distributions
Useful information which could be also missing:
|If you don't get feedback after a period of time, you can mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" (or resolution "BACKTRACE" if you are waiting for a complete backtrace)|
Often the bug reports aren't properly categorized, or they miss some information in the Bugzilla fields (which are useful for sorting and filtering):
Most of the times, the reporter user initially sets the bug report's title, and therefore, the summary doesn't really represent the bug itself. You may want to update the title to contain enough information to identify the issue properly.
A good title may contain:
|Try to use complete and easily readable english sentences as summary|
[patch] Plasma clock draws garbage when hovering it if the Ctrl key is pressed
Dolphin hangs when trying to view the properties of a big file
[testcase file] Plasma crashes when adding a special file to the panel [Class1::Function1, Class1::Function2, Class2::Function3]
Applications that use Plasma themes crash when compositing is switched on/off due an error in KPixmapCache [KPixmapCache::Private::mmapFile, KPixmapCache::Private::init, KPixmapCache::discard]
[testcase url] Konqueror shows a graphical artifact in webpage's form when scrolling
Some of the reports are assigned to the wrong product. This may happen because the original reporter didn't know to which application/library did the bug belong to. It may happen if the Crash Handler dialog reports a crash about an unsupported application (or one that is not mapped properly)
|Remember to check the KDE related technologies list|
Sometimes, the reports describe general issues or are filed against common bugzilla products (like "kde" or "kdelibs"); or, on the other round, are filed against specific products (but the underling bug root cause is at some specific library, not directly related to the current bugzilla product assignee)
In both cases, if we don't need/want to reassign the report (because we aren't really sure about it), we can add the assignee of the other related products, or other developers mail address, to the CC list of the bug report. That means, this person (or people following a mailing list) will get notified about this bug report, and they might look at it.
To know whom to add to the CC list you can:
Common situation examples:
There is a policy in KDE bugtracker which establishes that different issues/bugs should not be mixed up in the same bug report, in order to keep the database clean and easy to read.
If any user adds information which is unrelated to the current bug report, gently tell him/her to write it down on a *different/new report. (The new issue described may be already reported somewhere else. In that case, you need to write a reference to the that bug report ID)
An important step of bug triaging is trying to reproduce the bugs, this means, using the information the reporters added to the bug report to force(recreate, reproduce, repeat) the bug in the application.
This is needed in order to differentiate random/race condition bugs of reproducible ones (which may be reproduced by developers too; and they can fix them)
|Testing bug reports may modify/alter your own desktop configuration; also, to try to reproduce some bugs you may need a clean pristine (or sightly modified) environment. I recommend you to perform tests on a separate KDE installation or a clean user. There is also a way to start KDE applications with a clean configuration, even under your current configuration (setting the KDEDIR environment variable at run-time to an empty directory).|
You may want to use this reference text to setup your testing environment: Preparing a testing environment
|When trying to reproduce a bug, and if there are more than one piece of information, at first glance, try to identify a *common situation*. (some data or context that is present in all (or most of) the cases). This kind of data may be the key to find out how to reproduce.|
If you could reproduce the bug:
A template of a comment for this situation could be:
I can reproduce the bug here using KDE SC x.y.z, Qt a.b.c on Distribution, Kernel d.e.f on XX bits. In order to reproduce I have to perform the following actions: 1- Action 1 2- Action 2 3- Action 3 4- Bug Appears Note that you need to have the X configuration set to Y, and use the Z library - Can anyone else confirm this ? Thanks
If you could not reproduce the bug:
A template of comment for this situation could be:
I couldn't reproduce the bug here using KDE SC x.y.z, Qt a.b.c on Distribution, Kernel d.e.f on XX bits. I tried performing this actions: 1- Action 1 2- Action 2 or 1a- Action 1a 2a- Action 2a However the bug didn't appear/the application didn't crash - Are you all using library X and this kind of configuration ? - Can you still reproduce this bug with an updated KDE SC version ? Thanks
Hopefully you will get feedback from the reporters and you could gather more information to try to reproduce the bug or close the report as WORKSFORME (or FIXED)
During your work you may need help on how to proceed, you can use this resources to get help:
We are planing to host bug triaging events (where new "students" can learn the tricks) named "BugWeeks" on a regular basis to help cleaning up the KDE bug tracker database.
The BugWeeks initiative is based on the Klassroom initiative in the KDE Community Forums
You can find more information about this at:
|When updating the bugzilla product or component, do not forget to reset to the default assignee|
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 distributions naming scheme examples you can look at How to obtain debug packages for every distribution.