Revision as of 00:02, 2 April 2010

Initial version by Dario Andres (2010-03). Corrections by Lydia Pintscher

Disclaimer

All this guide is based on my own experience (approximately 2 years) on the KDE bug tracker.

It may not work for you ;)

General Considerations

• Be polite: when you need to request information or feedback be clear and polite, and you will get more information in less time. 
Often Bugzilla is a place which involves discussions (about implementations, or even about contributors). Try to be concise and polite, respecting the others position while describing your own.

• Don't try to do too many things at the same time; otherwise you will end up with a headache.

If you are not familiar with the Bugzilla (KDE bug tracker system) interface, you may find this guide useful: Quick Introduction to Bugzilla

About getting permissions to work in the bug tracker

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)

 

Note
adding comments in the bug report is allowed for every user

Getting Started: Find what to work on (Different Approaches)

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.

Note: The two following techniques are complementary.

Check all the bug reports of the day

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.

Good:

• You get a complete view of all the reports
• You can easily recognize possible duplicates if the report titles are appropriate
• You can choose any report
• You can quickly clean the bugs that were filed recently (keeping them from rotting)
• You can get quick feedback from the reporter

Not so Good:

• You don't focus on one product
• You may not pay too much attention to every report, as you are triaging different kinds of reports
• You need a lot of attention to handle the different reports (at the ~same~ time)

This technique could be used every week (or every day)

Bugzilla Links (TODO)

• All the bugs (any type) reported today or the last week
• All the crashes reported today or the last week
• All the normal bugs reported today or the last week
• All the feature requests reported today or the last week

Check bug reports of a product over a period of time

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"). 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).

Good:

• You focus only on one product / topic, so you don't need to pay too much attention (pay attention anyways!)

Not so Good:

• The reports of the other application may rot if they aren't checked
• You may not get feedback if the report is too old or the reporter is not accessible anymore

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.

Bugzilla Links (ToDo)

• Template search for all the reports of any status, since 2008: any kind of report, crashes, normal bugs, feature requests
• Template search for all the open reports, since 2008: any kind of report, crashes, normal bugs, feature requests

Workflow of the bug triaging activity

Now that you have a list of bug reports, pick one !

Workflow Graphic (ToDo)

Handling reports: What to do with a bug report

There are several things that must be checked and "fixed" to make an initial bug report an interesting and useful peace of information for the developers to check.

 

Note
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 much 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.

Identifying duplicates

There are a lot of ways of identifying duplicate reports depending of the kind of bug.

General

• Search for duplicates should be done initially against the same product of the bug report you are triaging: 
If you don't find any related issue, you may need to search in a different product.

 

Note
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)

• You may want to filter out the results by date: you can select a date range since some years (or months ago) to "Now" (today)

(Link ToDo) List of related KDE technologies

For "normal" (non-crash) reports

1. Pick some "keywords" from the current report. This keywords need to explain the inner concept of the bug that was reported (they must represent it).
2. Perform a full search over the same product (read general note), initially on the "general" component.
 Initially, put the keywords in the title, and perform the search (this will only look for the keywords in the title)
3. If your search has results on it, check them all, reading the whole description and trying to identify the situation.
4. If you don't get any results, you need to go back and:

   • Change your keywords (tip: select thesaurus, or similar/related concepts); or
   • Use the keywords in the "Comments" field (so the search will look up in the bug description and comments too)

 

Note
when using more than one word in the "Comments" field you need to select the option "contains all of the words/strings"

 

Note
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)

For "crash" reports

1. Perform the same operation as with normal bug reports
2. Check for reports with duplicate backtraces: 
 (Read the Backtraces section below)

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")

Processing search results

• If you don't find any similar report then we should assume the new bug reports is "unique" (and valid). See next section


• If you find a similar bug report we have too choices:
  • If you are completely sure it is the same issue, you have to mark the report as duplicate. 

The bug report you initially picked (name it "copy") is going to be marked as duplicate of the original report (name it "main"). If "copy" has additional information that "main" doesn't have, you may want to add it. (Note: some details may look unimportant to you, but they may be important for developers who know about the application workflow and code. Also, adding a big amount of minimal/incomplete information you may end up generating a big and complete testcase)

  • If you aren't completely sure: you need someone else to double check your work. You may want to add a comment in the current report saying "This bug looks related to bug XXXXXX" (XXXXXX being the bug ID of "master"). Then, you should ask in #kde-bugs IRC channel for someone to look at your comment.

 

Note
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. 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 refers to the issue you are looking at.

C++ Backtraces (identifying crashes duplicates)

Definition

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"

Example

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
...

Description of a backtrace line

#NumberInTheStack MemoryAddress in Namespace::Class:FunctionMember 
(argumentThis=pointerValue, argument1=value, argument2=value, ...) at path/to
/source/code/file.cpp:linenumber

• #NumberInTheStack: is the order number in the function stack. The lesser, the nearer to the crash point. The smaller number may not be zero
• MemoryAddress: we don't put attention to this one.. Ignore
• Namespace: C++ namespace of the function. It may not be available if there are no namespaces. This could be also a class name if "Class" is an embedded one.
• Class: C++ class name of the function
• FunctionMember: C++ function name
• argumentThis=pointerValue : this first argument is often the memory address/pointer of the C++ object (example "this=0x91ec5f8"

other argument use the same form "parameterName=parameterValue"
• (..): arguments supplied to the function. This information may not be available if *debug information* is not present


• path/to/source/code/file.cpp:linenumber the path to the source code file that describes that function, and the line number. The path is the one found at build time. This information may not be useful if debug information is not available (in that case, the name of the library or application binary may be included. Example: /home/kde-devel/kde/lib/libsopranoclient.so.1)

Example:

#13 0xb759d5d7 in Nepomuk::ResourceData::determineUri (this=0x91ec5f8) at 
/home/kde-devel/kde/src/KDE/kdelibs/nepomuk/core/resourcedata.cpp:671

• The function is the number 13 in the stack
• Function's namespace: "Nepomuk"
• Function's class: "ResourceData"
• Function's function: "determineUri"
• The object "Nepomuk::ResourceData" which called to "determineUri" has the pointer "0x91ec5f8"
• The function is described (where it was build) at "/home/kde-devel/kde/src/KDE/kdelibs/nepomuk/core/resourcedata.cpp". It leads to the next function in the stack at the line number 671

Identifying the first (useful) backtrace functions

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

 

Note
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)

f the first backtrace functions aren't available (they are not there, or there are "??" )then we can't proceed without requiring more information (a more complete backtrace) [Ask for more information Todo Link]

Avoiding useless function calls

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 backtrace:

• Kernel/GLibC functions (__kernel_vsyscall, raise, abort)
• Functions from core/base libraries (libraries with filenames like libpthread.so.0, libc.so, libstdc++.so, libglib-2.0.so; or functions starting with "*__GI_"). You may also need to ignore calls to graphics drivers (like nvidia or libGL)
• Qt containers classes (QMap, QList, QLinkedList, QVector, QStack, QQueue, QSet, QMap, QMultiMap, QHash, QMultiHash)
• Qt deep core classes (QApplication, QCoreApplication, QBasicAtomicInt, QBasicAtomicPointer, QAtomicInt, QAtomicPointer, QMetaObject, QPointer, QWeakPointer, QSharedPointer, QScopedPointer, QMetaCallEvent)
• Qt misc functions (qt_message_output, qt_message, qGetPtrHelper, (starting with) qt_meta_)

Special cases (Advanced)

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).

Bugs caused by external issues (UPSTREAM/DOWNSTREAM)

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.

• Applications which use plugins may be easier to affect (like Plasma when using custom Plasmoids/widgets)

Distributions can also bring some trouble, specially with packaging.

Some problems that may cause bugs are:

• different versions among KDE packages (kdelibs at one version, kdebase at a different one)
• missing plugins (broken packaging) causing crashes or missing features.

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 this 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.

Check the report quality (and ask for missing information)

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.

• Check that report is English and that is easily understandable.


  • If it is not in English you may want to look for someone on the KDE group (IRC channels) that may translate it for you. Alternatively you can ask the reporter to use some online translation system (you won't get a clear explanation, but it is something).
  • 

If the explanation is not clear enough, and you think that the bug could be described in a image, you may want to ask for a screenshot [explanation of Bugzilla attachments]

• If the bug is a graphical glitch or issue, you may want to request a screenshot [explanation of Bugzilla attachments]
• If the issue involves any other component (like the graphics card or drivers) you may need to ask for the versions and component's names
• If the bug report is about a crash and the backtrace information is not really complete (and you couldn't perform a duplicate search) you need to ask the user to install the missing debug package symbols, reproduce the bug and generate a new backtrace. Template for this request:

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:

• Application version
• KDE Platform (and/or Software Compilation) version
• If the bug is about a crash, request the version of the Qt library
• If the reporter is using an development version, request the SVN revision of the KDE platform and application

Setting Bugzilla fields (and re-assignation)

Trying to reproduce the bugs

Getting bug triaging support

BugWeeks

FAQ

More Information