Jump to content

Guidelines and HOWTOs/Bug triaging/Identifying duplicates

From KDE Community Wiki
< Guidelines and HOWTOs | Bug triaging
Revision as of 21:15, 31 January 2023 by Alem (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Identifying duplicates

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

General

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




 
Tip
You can search in different products at the same time


Note

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)


List of related KDE technologies

  • You may want to filter out the results by date: you can select a starting date from some years (or months) ago

For "normal" (non-crash) reports

  1. Pick some "keywords" from the current report. These keywords need to explain what the bug is about
  2. Perform a full search over the same product, initially in the "general" component.
 Put the keywords in the summary field, and perform the search
  3. If your search has results in 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)

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


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

Processing search results

  • If you don't find any similar reports then we should assume the new bug report is unique.

  • If you find a similar bug report we have two 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 is going to be marked as duplicate of the original report. If the duplicate has additional information, you may want to add it to the original. 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. Then, you should ask in the #kde-bugs IRC channel for someone to look at your comment.

Comment template: 

This bug looks related to bug XXXXXX

(XXXXXX being the bug ID of "master")

Note

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.


Identifying duplicates (crashes) : C++ Backtraces

Definition

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

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 number, the nearer it is to the crash point. The smaller number may not be zero
  • MemoryAddress: we don't pay attention to this one.. Ignore
  • Namespace: C++ namespace of the function. It may not be available if there are no namespaces. This could also be 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 arguments use the same form "parameterName=parameterValue"
  • (..): arguments supplied to the function. This information may not be available if debug information is not available
  • 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 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.

Note

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

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

  • 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 container 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, functions starting with qt_meta_)

Special cases (advanced)

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

List of related KDE technologies

  • Every KDE application use kdelibs [Bugzilla product: "kdelibs"]
  • Applications using the standard KDE file operations use KIO [Bugzilla product: "kio"] and probably KFile (for the UI part) [Bugzilla product: "kfile"]
  • Oxygen widget style (default) [Bugzilla product: "oxygen" component "style"] (component is included because "Oxygen" also refers to Plasma and icon themes)
  • Multimedia usage: Phonon library [Bugzilla product: "Phonon"]
  • PIM related applications use kdepimlibs, Akonadi and kresources technologies [Bugzilla products: "kdepim", "kdepimlibs", "Akonadi", "kresources"]
  • Applications using KHTML [Bugzilla product: konqueror"]
  • Applications using OpenDesktop services uses Attica [Bugzilla product: "attica"]
  • Screen management related operations use the Kephal subsystem [Bugzilla product: "kephal"]
  • Games use libkdegames [Bugzilla product: "libkdegames"]
  • Scanning related applications probably use the KSane lib [Bugzilla product: "libksane"]
  • Multimedia applications reading audio tags use taglib [Bugzilla product: "taglib"]
  • Hardware related functions use Solid classes [Bugzilla product: "solid"]
  • Power Management functions use PowerDevil [Bugzilla product: "solid", component: "powerdevil-daemon"]

Debug package names for several distributions

For every KDE application it is recommended to install the debug information for "kdelibs" and "qt4"

Package Ubuntu/Debian OpenSuse Fedora Mandriva
kdelibs kdelibs5-dbg kdelibs4-debuginfo kdelibs-debuginfo kdelibs4-debug
qt libqt4-dbg libqt4-debuginfo qt-debuginfo qt4-debug
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.

Retrieved from "https://community.kde.org/index.php?title=Guidelines_and_HOWTOs/Bug_triaging/Identifying_duplicates&oldid=95710"