Installing debug symbol packages from DrKonqi

This time I am not going to blog about KCall, but about DrKonqi. Dario Andres and I, the drkonqi maintainers, are thinking of adding some new features for KDE 4.4. As you already know, most distros out there ship stripped binary packages with their debug symbols put in separate packages. One of the features that we want to add in drkonqi for KDE 4.4 is to make it able to install the required debug packages when there are missing symbols in a crash report.

Our first idea for implementing this was to have a shell script installed somewhere, which by default will do nothing, and let distributions customize it to install the required packages. The input given to the script is the executable name and all the libraries that appear in the backtrace with missing debug symbols. For example, a backtrace line that reads like “#5 0xbf123456 in ?? from /usr/lib/” probably means that the library “/usr/lib/” is missing debug symbols, so that library path is passed as an argument to the script.

This is already implemented in trunk (it was very easy to do), but I now want to go further than that. Being a debian packager myself, I attempted to write an utility to do this for debian. I found an easy algorithm that takes as input all the filenames of the binaries that need debug symbols and outputs the names of the packages that need to be installed, using apt-file as a backend for searching package contents. While working on this, I came up with the idea to put this algorithm in a KJob, which eventually made me think of another possible implementation of this feature: Have a unified GUI in drkonqi that takes plugins; every distro will have its own plugin and each plugin will export a KJob that will do all the work (finding and installing packages), or alternatively, that KJob will only find the packages that need to be installed and then drkonqi will use packagekit to install them or display some message to tell the user what to install if packagekit is not available (which is the case for debian, btw).

This scenario would be better than the scenario with the script, because it will allow us to have a unified GUI in all distributions and will also reduce the work of the distributors, as they will have to write only one small plugin instead of a whole application to do all the work. I don’t know however if this scenario works for other distributions, as I don’t know how they handle debug packages.

So, dear fellow packagers and anybody else who has an opinion on this, I would like to know how your distribution handles debug packages and what is your opinion on all this, so that I can decide what to do and how to do it. 🙂


29 thoughts on “Installing debug symbol packages from DrKonqi

    1. I don’t know what are the capabilities of packagekit, but the problem is that even if packagekit can do all this magic by itself, this is not yet a perfect solution, because some distributions, or at least debian, are not using packagekit and do not plan to use it in the near future.

      1. A fallback would be nice for other distros, but I think the right way is PackageKit.
        Fedora, openSuse, Ubuntu and Mandriva all have them, so you can target the most easy distributions.
        Debian is trying to work on the issue (they’ll have it at some point):

        Moreover, I mean, if you do know how to use Debian / Slackware / Arch / Gentoo, you also do know how to install debug packages, right?

        Elseway you should consider also supporting *BSDs, Windows, Mac, and all the platforms KDE *theoretically* works in.

        1. packagekit would actually help to do this, if somebody makes a packagekit backend for bsd, windows or mac.

          so yeah, i think for kde packagekit is the way to go for all the package management, everything else is not maintanable on long term.

            1. I doubt that, since kubuntu (apt) and fedora (yum) use it by default. others are comming too (suse?). So at worst it’s a chicken egg problem, it could probably be better, but as soon as more applications use it, it will become better (that beeing said, packagekit works just fine on my kubuntu)

  1. This brings up 2 different points:

    (1) properly integrated package-management would be great for the free desktop. When I say properly integrated I mean that the desktop “knows what the packages mean” so you can install things like missing plug-ins from within an application.

    (2) it would be nice if users didn’t have to install debug packages at all. surely it is often more efficient to look up the symbols on the server than for every user to download packages for themselves.

  2. gdb already displays the required -debug packages when asking for a backtrace under Mandriva. I wonder how it works, but it’s a nice feature missing in drKonqi !

    For the rest, I agree with the others : packagekit is the way to go as you have the hat a KDE developer, even if not used by all distros (including Mandriva ; it’s not the default, at least). You can always have your “script idea” as a fallback if packagekit is not used.

  3. If you want distros to buy in to this, I think using a script is the way to go. A developer is a lot less likely to develop and maintain a binary plugin than a script.

  4. Remember aRts? I’d say package kit is not *the* way to go. If it isn’t widely supported on all platforms, you’re saying to people that don’t use a supported platform “too bad, so sad, get a real distro.” But.. you’re shooting yourself in the foot because the fire-and-forget bug reporters don’t give a shit whether their distro uses packagekit or not, and only care whether they have debug symbols if they think it’ll get them a quick fix.

  5. So you prefer to basicaly rewrite packagekit (even in a much simpler version) with a backend for each platform? I can’t see how that can work out over the long term. With packagekit you get that stuff for free, it’s maintained, cross desktop (which means it’s even more supported since gnome starts to use it more and more too). packagekit is more like phonon that artsd

    1. Cross desktop, as in being a pure gnome project, using gnome libraries. I wonder what people would say if it used QtCore?

      And it’s barely maintained. Only the distros paying for it have a maintained backend.

      The API it has is also less than elegant, and doesn’t fit in a lot of use cases (try asking wkai who tried to implement support for it in Shaman :-).

      I would say that a simple shell script is much, much simpler and more maintainable that the huge unmaintainable and unportable beast that packagekit is. It hasn’t even had a stable 1.0 release yet.

      1. > It hasn’t even had a stable 1.0 release yet

        Nor openssl has it till now. So don’t use openssl.

        I don’t care the numbering, I care the state of the project. The problem is now just to get the fact: is it really unmaintained as you say? Why do you say that?

        1. Is their API stable?

          And with unmaintained I mean that noone works on most of the backends. The exceptions are the distros who pay for developers to work on their backends. Just go look in their git repo.

    2. No, I’d say write a packagekit backend, and backends for those distros that don’t use packagekit. Much better than declaiming packagekit “best of breed” and saying “screw you” to those that have the temerity to use a distro that doesn’t have packagekit.

      Packagekit is *not* like Phonon, packagekit is like GStreamer – a non-KDE backend. We need an abstraction layer between packagekit and KDE for the same reasons one is needed between KDE and the various audio backends.

  6. Can DrKonqi save the core file to a safe location on occasions when debuginfo packages aren’t available?

    Until automated debuginfo installation is implemented a user (e.g. me) may not know the name of the debuginfo package. They may find out later and install the package. However for elusive bugs it may be difficult to recreate the problem and get a fresh stack trace.

    Another reason for saving cores could be the user doesn’t have Internet access at the time, but would like to submit a bug report later when connectivity is restored.

    DrKonqi would need to be enhanced to allow analysis of a core file, in addition to the existing on the spot analysis of crashes.

    1. Unfortunatelly, I asked the experts and they told me that coredumps can’t be generated after the application crashed and DrKonqi is already shown (due to technical reasons). Also, distributions disallow the creation of coredumps by default too.

      Currently you can save the backtrace (or the report with versions and other data) to a file to report later. But allowing DrKonqi to report a saved crash could be a bit excessive. (Anyways, if a crash is not happen regularly or “at will”, it is already difficult to try to fix)


      1. I’m not familiar with how DrKonqi captures its data. I had assumed that the crashing application produced a core dump and then DrKonqi ran as a separate application, which analysed the core dump. Hence I had thought that DrKonqi could present the option of moving the core from a temporary location to somewhere more permanent for later analysis. Sounds like that’s not the case.

        From what you’ve said, I’m wondering if DrKonqi runs within the same process that is itself crashing. For example is DrKonqi installed as a signal handler for SIGSEGV?

        If DrKonqi is running within the crashing process, would calling abort() from within the SIGSEGV handler be a way to provoke core dumping?

        Given that DrKonqi has a reload button to refresh the stacktrace (e.g. after installing debuginfo packages), would it be possible to save the data it is analysing off to disk for future analysis?

        In my case not knowing the debuginfo package names was the problem. Having DrKonqi help install them eliminates most of the need for saving cores for future analysis. However not having an internet connection at the time of the crash could still be an issue for some.


        1. Drkonqi runs as a separate process, but it is called from a signal handler, yes. The signal handler just launches drkonqi and puts the process to sleep. Drkonqi then externally launches gdb on the process and gets a backtrace. There is no core dump involved. When drkonqi exits, the signal handler calls exit(255), so the crashed process quits normally. Calling abort() would result in recursively launching drkonqi again, as the same signal handler would pop in. I guess there is a way to work this around, but still we want the process to live until drkonqi exits… It’s a bit complicated to implement.

          Saving the data that drkonqi gets from gdb is already implemented. There is a “save” button there 😉 But that just saves the backtrace in a plain text file, there is nothing more to save.

          1. Calling abort() would trigger a SIGABRT. Provided no signal handler was registered for that, then a core should be produced without triggering DrKonqi, which would be registered for other signals such as SIGSEGV. However perhaps we want DrKonqi to analyse other abort() calls, such as assert() failures.

            Alternatively when DrKonqi is first triggered, set a flag so that DrKonqi isn’t triggered again for further bad signals. Care would need to be taken with signal reentrancy issues – signal handlers are difficult to get right.

            A third approach – to make it safer, the crashing process, when instructed by the DrKonqi application, could fork(), restore signal handlers to their defaults and then call abort(). That way you’d get a core from the (identical) child and leave the original crashing child unaltered.

            The crashing process only fork()s and abort()s on command from the DrKonqi application, when the user hits the (yet to be implemented) “save core” button.

            Does that sound practicable, and is it worth the effort?

  7. Gentoo, has a keyword in make.conf called splitdebug. It would be enough to post a message informing users about this on Gentoo.

  8. Check ABRT – Fedora’s Automated Bug Reporting Tool, they have working debug info downloading already. I don’t know current state, so I don’t know how they are doing it but it could be inspiration for you. ABRT is quite plugable with different backends. I think some plugable integration with Dr. Konqui would be great. Guys working on it already contacted me as I’m the only one KDE guy here 😀
    I’ll check your code, feel free to contact me (or ABRT developers), I think it would be great to work together. They currently support only Gnome frontend and we’d like to have KDE one and integration with Dr. Konqui (ABRT is more low level tool).

  9. I use Kubuntu, and I pretty much install the debug packages for everything KDE related. An easy way to install all the debug packages for KDE apps installed would be great.

  10. In Debian, we plan to create a special archive for packages with debugging symbols. It would be easy to map normal packages with debug packages, and install those.

    Moreover, we want to ship debugging symbols directly though the network via a WebDAV share or something like that. That way for Debian, you could just mount it, and tell gdb to use that mountpoint as the global debug directory (set/show debug-file-directory), and the files would be downloaded as needed, in a transparently way for DrKonqi, providing there is network access.

    A way to install the packages makes sense too, maybe both options could be provided.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s