Opportunistic KDE/Kubuntu Debugging

Back in the days, we did not have capabilities to find and install debug packages with Dr. Konqi in KDE. But those times are over!

Debug packages are important, well, actually very important. When an application crashes it is in most cases possible to create a so called backtrace. A backtrace ideally provides the developer with the precise location in the source code where the crash happened. Fixing a crash without this kind of information is almost impossible, and the more information are available in the backtrace the better. Debug packages contribute to this in that their content are debug symbols, essentially those are the references that are used in the backtrace. Now, usually you do not need to have this information to use the software, which is the reason a lot of distributions strip the symbols into these seperated debug packages (one can save a big deal of disk space by removing them).

In case you did not yet hear of Dr. Konqi. It is a very useful tool that usually pops up when a KDE application crashes. It then tries to get all information necessary for you to create a perfectly useful bug report.

There is big of a problem, on the one hand you do not want to waste disk space and network traffic for these debug symbols, even though like 99% of the regular users will not need them, and on the other hand you have Dr. Konqi which is trying to obtain a high quality backtrace that enables developers to quickly process a bug report and fix a crash in their software.

Not KDE 4.4not GNOME 3.0 and not KDE SC 4.4but Dr. Konqi 2.1 comes to rescue and now allows distribution developers to create scripts that take care of the find an installing of debug packages, so that the debugging experience becomes a bit better. Well, obviously debugging is not much of a user experience eitherway😉 but at least getting a backtrace is now more barable than it was before.

The system is quite simple. Dr. Konqi calls an executable, passing it all files for which no debug symbols were found for as arguments, then the executable tries to find and install the appropriate packages and returns back to Dr. Konqi. Straight forward really🙂

Since I am, amongst other things, Kubuntu developer and since this blog post is tagged ‘kubuntu’ of course I am only blogging about this because Kubuntu today got support for this fancy new feature😉. Should you encounter a crash in upcoming Kubuntu 10.04 Dr. Konqi will not only tell you how good the quality of the automatic generated backtrace is, but also show a button with which you can install missing debug symbols.

Additionally I might mention that Kubuntu has a new mantra of using C++ whenever possible (in opposite to the former one, which was to use Python whenever possible), hence the application standing behind this new features is written in C++ and got the fancy name kubuntu-debug-installer.

In case you care, the code is available on launchpad, and fairly simple. It really just creates a thread and uses dpkg -S to find the appropriate packages. In later versions it will also be able to use other means of looking up debug packages and be able to add a super secret Kubuntu repository for debug packages automatically, if necessary.

What I would like to see for future KDE releases is the possibility to directly tie a plugin into Dr. Konqi instead of having to create an independet application. But for now we’ll try to get kubuntu-debug-installer the ability to use different algorithms for finding the appropriate debug packages (also using different tools, since for example apt-file performs better than dpkg-query, but requires an up-to-date cache etc.) and of course support of a special Kubuntu repository that contains debug packages for all and every official Kubuntu package.

23 thoughts on “Opportunistic KDE/Kubuntu Debugging

  1. Dear Harald,
    it’s not called KDE 4.4. Did you miss the rebranding? It’s now KDE SC 4.4. “KDE” itself is just the organization.

    • True. All fixed up🙂.

      Indeed the notation here is all wrong anyway, since it is not the large amount of software that makes up the SC that rescues us, but indeed it is just the new drkonqi😉

    • That’s quite pointless pedantry. It’s blatantly obvious that it can’t be the community which is at version 4.4, but only the software. So insisting on the “SC” part is just redundant.

  2. Description should be user proof. Names like debug, symbols, etc, are not really descriptive for a normal user, should a crash occur. A more generic description, like “Program XXX crashed. The automatized crash report system needs additional information to proceed. Do you agree installing the following packages to help solve the problem?”

    • I generally would agree, but in this particular case it is more than unlikely that a user who does not understand what a debug symbol is, even gets to this dialog without getting lost in all the madness. Currently this debug package lookup does only get done if a user requests it. Though yes, the dialog could use more clearity eitherway. Thanks for the suggestion🙂

    • Yeah, in theory Kubuntu was always my favourite distribution because I like how it doesn’t have a lot of own tools (YaST, Mandriva Control Center) and Ubuntu/deb/apt as a base, but the actual releases always had there problems (translations, bad decisions etc.). Kubuntu 10.04 however leaves no room for much critizism if at all🙂

  3. Hi Harald,

    I have used Kubuntu from the beginning since 5.04,

    Must say, thanks for all your valuable time and effort. Keep up the good work – really looking forward to 10.04.

    If you get the time, please blog again on how project Timelord is going!!

    Regards

    MATT

    • Debug is enabled by default? If you mean that they should ship and install the debug symbols, then that is simply an impossible thing to archive with CDs, as it is we are constantly fighting for space😦.

  4. Great to see that feature implemented🙂

    You say you would like to see this implementable with DrKonqi plugins. That was one of the first methods I considered when I designed the interface, but I soon dropped it because it is difficult to maintain a common interface for all distributions, plus that C++ may not be suitable for everyone, plus that people may want to implement this feature directly in their package managers. So, imagine a distribution having something like ” –install-dbg-symbols /usr/bin/konqueror”, another one that doesn’t ship debug packages (having gentoo in my mind here) just showing a message box with instructions on how to build with debug symbols, etc…

    Now, speaking with my debian hat, I’m probably going to implement a similar tool in debian sooner or later and I am thinking that we could probably share some code. Debian can’t use kpackagekit though, so probably the only part that can be shared is the searching algorithm. I like the way that you query packages with dpkg-query. I hadn’t thought of that solution originally, so my sample script uses apt-cache, which however requires its data to be updated manually. Your solution is obviously better. Anyway, I’m just dumping my thoughts here, I am not sure yet what I’ll do exactly… I’ll let you know when I decide.

    Regards

    • My plan is to make the installer more generic, so that it also becomes suitable for Debian and other distributions (also other name + move to KDE playground ;)). This mostly means to have backend interaction interaction limited to hand-list-of-files-to-thread-and-wait-for-signals. This way we could have some additional backenend magic, like for example first query apt-file and only if that fails query dpkg, because a dpkg query is quite slow on large installations, so it makes sense to use other tools, if they are available.

  5. How about implementing an online lookup?
    Users won’t have to install the debug packages themselves which also can save bandwidth.
    However, you need some infrastructure with a database – I have no idea how complicated this would be.

  6. I’m running Kubuntu 9.10. I don’t see to have a drkonqi. When Firefox crashes it runs a similar tool (apport-kde ?) that eventually tells me I don’t have the needed packages for useful crash info and gives me a vague link to info on debug packages, so this sounds like an improvement.

    https://wiki.kubuntu.org/KubuntuKarmicApport says “Apport provides [complete crash reports with useful backtraces] and more complete reports than Dr Konqi, the KDE crash handler”, so perhaps using apport-* for Karmic is intentional. If that’s changing for Lucid, maybe the conclusions of https://wiki.kubuntu.org/Kubuntu/Bugs/Apport/Discussion need to be updated. Will Dr. Konqi handle crashes in non-KDE apps (90% of mine are firefox and flashplugin)?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s