GNOME Bugzilla – Bug 331004
Should fetch debug metadata automatically if possible
Last modified: 2018-07-16 08:25:05 UTC
BB tries to do use gdb and do "bt" to get a backtrace from a crashed app. If the app is stripped, this won't yield much useful information. If the application is some kind of official build made by a Linux distributor or whoever, BB should be able to fetch debug metadata for the application before attempting to do the backtrace. The Ubuntu people have an outline of this kind of feature here: https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports At the time of writing they aren't putting any resources into it.
*** Bug 347556 has been marked as a duplicate of this bug. ***
Very hard to do, but of course the thing we want the most (confirming so people understand it is wanted). Would love people who have enough ideas/experience to fix this bug (first version doesn't have to support more than one distro, as long as it is extensible somehow).
A more low-hanging fruit temporary solution could be this: What if bug-buddy read through the stack trace collected, and if it noticed that debugging symbols are missing gave the user a message on how to install debugging symbols, the url to l.g.o/GettingTraces, and no submit button... But of course, the features you are describing here would be the ideal! (Olav: tried posting this as a comment to your blog, it seemed to think it was spam, please look into it)
I was about to report such a enhancement request and found that bug. The most important point is to allow the user to install the package and re-generate the stacktrace then, as this will allow getting a valid trace even if the user does not know how to reproduce. I think that most of the time we will get the list of libs in the trace, even when we do not have the symbols. The distrib specific part would get a list of files (the libs or binaries) and offer the user to setup the needed sources and install the associated debug packages. It would be quite easy I guess, on a rpm based distro the algorithm for mapping a file to a -debug package is (only tested on Mandriva) : $ rpm -qf --qf "%{SOURCERPM}\n" /usr/lib/libz.so.1.2.3 | sed 's/-[^-]*-[^-]*$/-debug/' zlib-debug
As a first step, could bug-buddy have an option to manually regenerate the backtrace after debug packages are downloaded? I can look at a backtrace and see which packages are needed, but I can't regenerate it from bug-buddy after I've downloaded them.
*** Bug 539128 has been marked as a duplicate of this bug. ***
From that last duplicate report: I originally logged a feature request on fdo for PackageKit to do this. This is what I wrote: http://bugs.freedesktop.org/show_bug.cgi?id=16359 "...given that PackageKit seems to have the ability to know what package the app is part of, then the crash reporting software could ask PackageKit to find out what symbol package is available for the software, then PackageKit could download and install it after being prompted, then the software provide a proper stacktrace with symbols. This would help alleviate the many, many bug reports without any symbols. I'd imagine it would certainly help the app developers out!" However, Richard Hughes has suggested that the feature request would be better put towards the bug-buddy devs. He wrote that: "Yes, although I don't think this should be part of PackageKit - I think the application just needs to /use/ PackageKit to install the correct packages. I think that bug-buddy really needs to be patched to use PackageKit rather than make any modifications to PK itself. Could you open a bug against bug-buddy and see how receptive they are there? Thanks." So I'm wondering if this seems to be a good idea? Certain I've not seen bug-buddy be able to do this, but I certainly have seen quite a lot of bug reports without readable stack traces due to a lack of debug symbols. What do people think?
I was having the same idea, and would like to work on it for 2.26. Richard, could you please point me to a code example on how to use that API? Reading from the documentation I assume I should use pk_client_search_name/file with the appropriate filter, but I couldn't figure out the steps that I have to do after that to actually install the package.
No problem: http://packagekit.org/pk-faq.html#session-methods -- it all depends on whether you want to depend on a session running (easy) or use the low level interface (bit harder). Yell and I'll help you write all the code you need.
(In reply to comment #8) Cosimo, any news in this field?
Also see this: http://blogs.gnome.org/hughsie/2009/06/29/abrt-and-pk-debuginfo-install/
Hi all, there doesn't seem to be any traction on this idea... is there any reason why
(In reply to comment #12) > is there any reason why Missing manpower. Patches welcome...
If only I had the ability... sorry, was only wanting to see if this was still on the radar.
bug-buddy is not under active development anymore and had its last code changes many years ago. Its codebase has been archived: https://gitlab.gnome.org/Archive/bug-buddy/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality (see bug 796784). Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.