DebuggingKDE

Differences between revisions 13 and 14
Revision 13 as of 2010-01-23 01:38:17
Size: 11478
Editor: p54A2303F
Comment:
Revision 14 as of 2015-03-29 13:17:24
Size: 10849
Editor: penalvch
Comment: Added support note on missing -dbg symbols when using reporting assistant.
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
 1. Hardware specific bugs - The developers may not have access to the hardware that triggers this bug. Certain log files and command outputs can help.  For KDE, this can be relevant e.g. in configuration dialogs.  1. Hardware specific bugs - The developers may not have access to the hardware that triggers this bug. Certain log files and command outputs can help. For KDE, this can be relevant e.g. in configuration dialogs.
Line 16: Line 16:
Line 19: Line 20:
Line 22: Line 24:
Line 23: Line 26:
Most parts of KDE use [[http://bugs.kde.org|KDE's Bug Tracking System]].  If you think a bug is in KDE and not Kubuntu specific, please search for it at [[http://bugs.kde.org|KDE's Bug Tracking System]] and file one there if need be.  Link the upstream bug in the Launchpad bug by clicking "Also Effects Project."  A bug with an upstream report should usually be "''Confirmed''" (you often shouldn't file it upstream if it's not).  These bug reports can do a lot to improve the next version of KDE.
== Projects using Launchpad ==
=== Katapult ===

Most parts of KDE use [[http://bugs.kde.org|KDE's Bug Tracking System]]. If you think a bug is in KDE and not Kubuntu specific, please search for it at [[http://bugs.kde.org|KDE's Bug Tracking System]] and file one there if need be. Link the upstream bug in the Launchpad bug by clicking "Also Effects Project." A bug with an upstream report should usually be "''Confirmed''" (you often shouldn't file it upstream if it's not). These bug reports can do a lot to improve the next version of KDE.
Line 45: Line 47:
For information on how to debug KDE applications, see: Every official KDE module has an additional package in the repository, suffixed with -dbg.

== Debugging a crash ==

Applications by default on Kubuntu will generate useless backtraces when they crash. To get useful backtraces, all debugging symbols for the application need to be installed.

When utilizing the Crash Reporting Assitant, this should give you the opportunity to install the necessary debug symbol packages. However, if one gets a window noting the following example: {{{
Missing debug information packages
The packages containing debug information for the following application and libraries are missing:
/usr/bin/plasmashell
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
}}} Then one needs to manually enable the additional debugging symbols by folowing the instructions from [[https://wiki.ubuntu.com/DebuggingProgramCrash|here]].

For additional information on how to debug KDE applications, see:
Line 50: Line 68:
== Packages with Debugging Symbols ==
Applications as installed by default on Kubuntu will generate useless backtraces when they crash. To get useful backtraces, you need to install the package with debugging symbols for the application.
= How to Triage =
Line 53: Line 70:
Every official KDE module has an additional package in the repository, suffixed with -dbg. Always install kdelibs-dbg, because all KDE applications use kdelibs. Then you should install a -dbg package for the application which crashed. For example if KOrganizer crashed you should install kdepim-dbg as well. See [[DebuggingKDE#head-700ed3979b895dbb8fa78c9516ed89c536bea345|choosing the right package]] to help figure out what module an application is in. For KDE4 on Hardy, these will be -dbg-kde4.

= How to Triage =
You can find information on what triaging is and how to do it at [[Bugs/HowToTriage|HowToTriage]]. Here are some pointers as well:
You can find information on what triaging is and how to do it at [[Bugs/HowToTriage|HowToTriage]]. Here are some pointers as well:
Line 59: Line 73:
Line 63: Line 78:
 * Sending bugs to their upstream authors, when applicable.  For KDE this is http://bugs.kde.org  * Sending bugs to their upstream authors, when applicable. For KDE this is [[http://bugs.kde.org]].
Line 70: Line 85:
Line 77: Line 93:
 * Unconfirmed ("''New''") bugs are a priority.  An unconfirmed bug isn't of much use to a developer or to the reporter. It's a waste of developers' time to try to figure out if things are even real bugs, so that's our job.  Do your best to reproduce bugs so that you can confirm them.
 * Bug reports often lack essential information required to fix them or to find out if they are already fixed.  This can range from basic information such as what release they are using or even what program the bug is in to slightly more complex things like stack traces for crashes.  Ask the reporter for any missing information.  Be clear and polite.  When you ask questions, mark the bug status as "''Incomplete''" until all the required information is provided.  If you can reproduce the bug, provide the information yourself and mark "Confirmed."
 * Duplicate bug reports are common.  When you are looking at a new bug, open up another window and do an advanced search for similar bugs, including ALL bugs -- closed and open.  If you are certain a bug report is a duplicate, mark it that way and comment on the bug to inform the reporter.  Usual responses for this can be found [[https://wiki.ubuntu.com/Bugs/Responses#head-c9465ec0d0c312bab06eac061dbdc6d2071204d1|here]].  Other than this, avoid commenting on bugs marked as duplicates -- comment on the root bug.
 * Many bugs have already been fixed.  For older bugs that you cannot reproduce, ask if the reporter is sill having the problem.  If the problem was fixed with an update that can be identified, you can close the bug as "''Fix Released''".  If the problem just magically went away, close the bug as "''Invalid''".
 * Bugs that are marked as "''Incomplete''" for over 3 months with a clear request for information but ''without a response'' that you ''can't reproduce'' aren't particularly useful.  They should be closed as "''Invalid''".  When closing a bug for this reason, be polite and inform the reporter why you are closing it, and tell them that they can reopen the bug if they still have the problem and can provide the needed information.  Some responses for this can be found [[https://wiki.ubuntu.com/Bugs/Responses#head-aa72b6a41481a1304f6cc8dc0b076db1c288ff10|here]].
 * If you think a bug is in KDE and not Kubuntu specific, please search for it at [[http://bugs.kde.org|KDE's Bug Tracking System]] and file one there if need be.  Link the upstream bug in the Launchpad bug by clicking "Also Effects Project." A bug with an upstream report should usually be "''Confirmed''" (you often shouldn't file it upstream if it's not).  These bug reports can do a lot to improve the next version of KDE.
 * Pick an application that you use a lot, and concentrate on it.  This helps narrow down the list of bugs you are looking at and makes the work much more manageable.  It also helps to be knowledgeable in the program(s) you are doing bug work for.
 * If you have some rare configuration, look at bugs relating to it. For example, if you have a dual monitor setup, try to confirm some xinerama/xrandr related bugs.  This is particularly helpful since many other people who come across those bugs have no way of doing anything with them.
 * Unconfirmed ("''New''") bugs are a priority. An unconfirmed bug isn't of much use to a developer or to the reporter. It's a waste of developers' time to try to figure out if things are even real bugs, so that's our job. Do your best to reproduce bugs so that you can confirm them.
 * Bug reports often lack essential information required to fix them or to find out if they are already fixed. This can range from basic information such as what release they are using or even what program the bug is in to slightly more complex things like stack traces for crashes. Ask the reporter for any missing information. Be clear and polite. When you ask questions, mark the bug status as "''Incomplete''" until all the required information is provided. If you can reproduce the bug, provide the information yourself and mark "Confirmed."
 * Duplicate bug reports are common. When you are looking at a new bug, open up another window and do an advanced search for similar bugs, including ALL bugs -- closed and open. If you are certain a bug report is a duplicate, mark it that way and comment on the bug to inform the reporter. Usual responses for this can be found [[https://wiki.ubuntu.com/Bugs/Responses#head-c9465ec0d0c312bab06eac061dbdc6d2071204d1|here]]. Other than this, avoid commenting on bugs marked as duplicates -- comment on the root bug.
 * Many bugs have already been fixed. For older bugs that you cannot reproduce, ask if the reporter is sill having the problem. If the problem was fixed with an update that can be identified, you can close the bug as "''Fix Released''". If the problem just magically went away, close the bug as "''Invalid''".
 * Bugs that are marked as "''Incomplete''" for over 3 months with a clear request for information but ''without a response'' that you ''can't reproduce'' aren't particularly useful. They should be closed as "''Invalid''". When closing a bug for this reason, be polite and inform the reporter why you are closing it, and tell them that they can reopen the bug if they still have the problem and can provide the needed information. Some responses for this can be found [[https://wiki.ubuntu.com/Bugs/Responses#head-aa72b6a41481a1304f6cc8dc0b076db1c288ff10|here]].
 * If you think a bug is in KDE and not Kubuntu specific, please search for it at [[http://bugs.kde.org|KDE's Bug Tracking System]] and file one there if need be. Link the upstream bug in the Launchpad bug by clicking "Also Effects Project." A bug with an upstream report should usually be "''Confirmed''" (you often shouldn't file it upstream if it's not). These bug reports can do a lot to improve the next version of KDE.
 * Pick an application that you use a lot, and concentrate on it. This helps narrow down the list of bugs you are looking at and makes the work much more manageable. It also helps to be knowledgeable in the program(s) you are doing bug work for.
 * If you have some rare configuration, look at bugs relating to it. For example, if you have a dual monitor setup, try to confirm some xinerama/xrandr related bugs. This is particularly helpful since many other people who come across those bugs have no way of doing anything with them.
Line 87: Line 103:
 * Don't duplicate efforts.  If there is already someone working on a bug and asking the right questions, move on to another one.  There are plenty to go around.  * Don't duplicate efforts. If there is already someone working on a bug and asking the right questions, move on to another one. There are plenty to go around.
Line 89: Line 105:
 * DO get on '''#ubuntu-bugs''' and '''#kubuntu-bugs''' if you need help, to discuss bugs, and to watch for incoming bugs. #ubuntu+1 can also be useful to discuss development release problems with other users.  Don't use #kubuntu for this.
 * DO get on '''#ubuntu-bugs''' and '''#kubuntu-bugs''' if you need help, to discuss bugs, and to watch for incoming bugs. #ubuntu+1 can also be useful to discuss development release problems with other users. Don't use #kubuntu for this.
Line 98: Line 113:
TODO: Description of known bug reports that may receive duplicates and how to recognise them. This information should be obtained by looking for bugs tagged as 'metabug'. == Other useful bug lists ==
Line 100: Line 115:
'''Open'''
||<rowbgcolor="#eeeeee"> '''Bug''' || '''Subject''' || '''Symptom''' ||
|| [[https://bugs.beta.launchpad.net/ubuntu/+source/synaptic/+bug/8896|#8896]] || The subject from LP || This bug can be identified by ... ||

'''Closed'''
||<rowbgcolor="#eeeeee"> '''Bug#''' || '''Subject''' || '''Symptom''' ||
|| [[https://bugs.beta.launchpad.net/ubuntu/+source/synaptic/+bug/8896|#8896]] || The subject from LP || This bug can be identified by ... ||

== Other useful bug lists ==
Line 113: Line 119:
= Non-bugs = = FAQ =
Line 115: Line 121:
TODO: How to recognise common issues arising from hardware failures, common feature requests and other invalid bugs for this category. Advice how triage them and stock responses.

= FAQ =
Why can't I change the importance of bugs?  Why can't I set Won't Fix or Triaged status?
 You need to be a member of the ubuntu-bugcontrol team on launchpad to change the importance of bugs.  This is mostly so people are responsible and don't raise the importance of their own bugs.  Get someone to help you and set it for you, and consider applying for membership once you have some experience.  See UbuntuBugControl for more information.
Why can't I change the importance of bugs? Why can't I set Won't Fix or Triaged status?
 You need to be a member of the ubuntu-bugcontrol team on launchpad to change the importance of bugs. This is mostly so people are responsible and don't raise the importance of their own bugs. Get someone to help you and set it for you, and consider applying for membership once you have some experience. See UbuntuBugControl for more information.

Debugging Central

This page is part of the debugging series — pages with debugging details for a variety of Ubuntu packages.

Introduction

Bugs relating to KDE typically fall into 3 categories:

  1. User interface bugs - require a detailed description of the issue, steps to reproduce and screen captures where appropriate.
  2. Incorrect Functionality - require a detailed description of the issue, steps to reproduce and screen captures where appropriate.
  3. Crasher bugs - Log files from the crash incident are required to track down these.

Some possible problems with bug reports include:

  1. Hardware specific bugs - The developers may not have access to the hardware that triggers this bug. Certain log files and command outputs can help. For KDE, this can be relevant e.g. in configuration dialogs.
  2. Package selection - Help to find the right package

How to file

See Reporting Bugs.

Choosing the right package

Usually you can find the right package in Launchpad by searching for the application. There is a lot of information about choosing a package at FindRightPackage. Here are some other useful guidelines for KDE components:

  • System Settings lives in kdebase-workspace, though is just the shell that gives you icons for the various settings modules. If you want to file a bug about a settings module, it should probably be against one of kdebase kdeadmin, or kdenetwork. Specifically:

    • knetworkconf, the manual network configuration module, is in kdeadmin

    • The filesharing module is in kdenetwork

    • Most others are in kdebase

  • Konqueror, Kate, and Konsole (and more) are in kdebase

  • Krunner, klipper, kscreensaver, ksysguard, kwin, and systemsettings are in kdebase-workspace

  • Knotify, kio slaves are in kdebase-runtime

  • Ark is in kdeutils.

  • If you have an issue consistent for all KDE applications, such as not being able to launch them, the problem is likely in kdelibs

For definitive information on what KDE module an application is in, see KDE SVN for KDE 3.5 and for KDE 4.0.

Upstream

bugs.kde.org

Most parts of KDE use KDE's Bug Tracking System. If you think a bug is in KDE and not Kubuntu specific, please search for it at KDE's Bug Tracking System and file one there if need be. Link the upstream bug in the Launchpad bug by clicking "Also Effects Project." A bug with an upstream report should usually be "Confirmed" (you often shouldn't file it upstream if it's not). These bug reports can do a lot to improve the next version of KDE.

Bug tags

Bug tags specific to the package or area should be included here for reporters so they can tag their bug report.

Note: When adding new tags, the Bugs/Tags wiki page should then be modified to include these tags.

Tag

Use case

`needs-upstream-report`

This bug needs the report to be forwarded to the upstream project

`upstream`

This bug is reported to the upstream project

`needs-upstream-sync`

This bug has been forwarded to the upstream project which has released a fix that has not been merged yet

`guidance-powermanager`

This kde-guidance bug is in powermanager

`kde-guidance-displayconfig`

This kde-guidance bug is in displayconfig

`kde-guidance-userconfig`

This kde-guidance bug is in userconfig

`kde-guidance-mountconfig`

This kde-guidance bug is in mountconfig

`kde-guidance-serviceconfig`

This kde-guidance bug is in serviceconfig

`kde-guidance-wineconfig`

This kde-guidance bug is in wineconfig

Debugging procedure

Every official KDE module has an additional package in the repository, suffixed with -dbg.

Debugging a crash

Applications by default on Kubuntu will generate useless backtraces when they crash. To get useful backtraces, all debugging symbols for the application need to be installed.

When utilizing the Crash Reporting Assitant, this should give you the opportunity to install the necessary debug symbol packages. However, if one gets a window noting the following example:

Missing debug information packages
The packages containing debug information for the following application and libraries are missing:
/usr/bin/plasmashell
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5

Then one needs to manually enable the additional debugging symbols by folowing the instructions from here.

For additional information on how to debug KDE applications, see:

How to Triage

You can find information on what triaging is and how to do it at HowToTriage. Here are some pointers as well:

What does triaging bugs mean?

  • Responding to new bugs as they are filed.
  • Reproducing and confirming bug reports.
  • Asking the reporter to provide missing information.
  • Searching for duplicates in the bug tracking system.
  • Sending bugs to their upstream authors, when applicable. For KDE this is http://bugs.kde.org.

  • Cross-referencing bugs from other distributions.
  • Classifying bugs by package.
  • Prioritizing bugs.
  • Expiring old bugs with missing information and no response.

Suggestions and rules

  • Read the wiki pages:
  • Be polite!

  • Unconfirmed ("New") bugs are a priority. An unconfirmed bug isn't of much use to a developer or to the reporter. It's a waste of developers' time to try to figure out if things are even real bugs, so that's our job. Do your best to reproduce bugs so that you can confirm them.

  • Bug reports often lack essential information required to fix them or to find out if they are already fixed. This can range from basic information such as what release they are using or even what program the bug is in to slightly more complex things like stack traces for crashes. Ask the reporter for any missing information. Be clear and polite. When you ask questions, mark the bug status as "Incomplete" until all the required information is provided. If you can reproduce the bug, provide the information yourself and mark "Confirmed."

  • Duplicate bug reports are common. When you are looking at a new bug, open up another window and do an advanced search for similar bugs, including ALL bugs -- closed and open. If you are certain a bug report is a duplicate, mark it that way and comment on the bug to inform the reporter. Usual responses for this can be found here. Other than this, avoid commenting on bugs marked as duplicates -- comment on the root bug.

  • Many bugs have already been fixed. For older bugs that you cannot reproduce, ask if the reporter is sill having the problem. If the problem was fixed with an update that can be identified, you can close the bug as "Fix Released". If the problem just magically went away, close the bug as "Invalid".

  • Bugs that are marked as "Incomplete" for over 3 months with a clear request for information but without a response that you can't reproduce aren't particularly useful. They should be closed as "Invalid". When closing a bug for this reason, be polite and inform the reporter why you are closing it, and tell them that they can reopen the bug if they still have the problem and can provide the needed information. Some responses for this can be found here.

  • If you think a bug is in KDE and not Kubuntu specific, please search for it at KDE's Bug Tracking System and file one there if need be. Link the upstream bug in the Launchpad bug by clicking "Also Effects Project." A bug with an upstream report should usually be "Confirmed" (you often shouldn't file it upstream if it's not). These bug reports can do a lot to improve the next version of KDE.

  • Pick an application that you use a lot, and concentrate on it. This helps narrow down the list of bugs you are looking at and makes the work much more manageable. It also helps to be knowledgeable in the program(s) you are doing bug work for.
  • If you have some rare configuration, look at bugs relating to it. For example, if you have a dual monitor setup, try to confirm some xinerama/xrandr related bugs. This is particularly helpful since many other people who come across those bugs have no way of doing anything with them.
  • Keep all this in mind when filing your own bugs.
  • Don't confirm your own bugs.
  • Don't duplicate efforts. If there is already someone working on a bug and asking the right questions, move on to another one. There are plenty to go around.
  • Keep in mind that while closing bugs is important, the key is that the bugs are FIXED.
  • DO get on #ubuntu-bugs and #kubuntu-bugs if you need help, to discuss bugs, and to watch for incoming bugs. #ubuntu+1 can also be useful to discuss development release problems with other users. Don't use #kubuntu for this.

Stock Reply

Responses to use when triaging

Known bugs

Other useful bug lists

Here are the major Kubuntu Desktop packages and their bugs: https://launchpad.net/~kubuntu-team/+packagebugs

A vague list of all the unconfirmed bugs in Kubuntu.

FAQ

Why can't I change the importance of bugs? Why can't I set Won't Fix or Triaged status?

  • You need to be a member of the ubuntu-bugcontrol team on launchpad to change the importance of bugs. This is mostly so people are responsible and don't raise the importance of their own bugs. Get someone to help you and set it for you, and consider applying for membership once you have some experience. See UbuntuBugControl for more information.

Also see


CategoryBugSquad CategoryDebugging

DebuggingKDE (last edited 2015-03-29 13:17:24 by penalvch)