| Summary: | DrKonqi doesn't install all required -debuginfo packages though they are available | ||
|---|---|---|---|
| Product: | [Applications] drkonqi | Reporter: | opensuse.lietuviu.kalba |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | CC: | bugseforuns, fabian, nate, sitter |
| Priority: | NOR | ||
| Version: | 5.17.3 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugzilla.suse.com/show_bug.cgi?id=1159234 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | backtrace example after automatic -debuginfo packages installation - still many ?? marks | ||
|
Description
opensuse.lietuviu.kalba
2019-12-07 10:20:48 UTC
Ugh, that looks annoying. Please report this to your distribution. Drkonqi only gives out a list of files it needs symbols for, actually mapping them to packages is done by distribution-provided technology, I expect something is going wrong there. OK, opened bug in https://bugzilla.suse.com/show_bug.cgi?id=1159234 The distro-specific handling of debug package installation is working as expected. Bug is not in openSUSE side, seems to be in KDE side. Maybe drKonqi analyses only Thread 1 (and ignores Thread 2...6)? Oh, I didn't read the trace properly. Sorry. You are absolutely right that it does in fact not care about anything but the stack with the signal handler (i.e. the likely crashing thread). I suppose there is a reason why it behaves that way, I don't really know I'm afraid. It does explicitly discard anything that isn't below the signal handler though, so this is most decidedly not by accident. Does this actually cause any problems? Usually drKonqi rates our backtrace (from 0 to 3 stars). If backtrace is not sufficiently full, drKonqi refuses to send bug report into bugs.kde.org. Backtraces in other threads do improve the rating (receives more stars), enhances chances that we will be able to send bug report. [Alternatively, there will be less problem, if drKonqi will not include other threads into evaluation of usefulness of backtrace] Perhaps we can re-word header of this bug to make it more clear. @Fabian, what do you think: should drKonqi care about other threads? Hard to say - in some cases, other threads are relevant to crashes, but that's pretty rare. Debuginfo is pretty big (more than 10x the binary size), so avoiding debuginfo which isn't needed is a valid goal as well. So I'd argue that drkonqi should just ignore other threads consistently. not a bug? or maybe we can turn this into enhancement request: add option to select whether install -debuginfo for other threads I'm not sure I'm too excited about adding checkboxes without use cases. When a user is capable enough to notice that other threads may be relevant (and thus tick the checkbox) I'd assume they also know how to manually install packages. At best the checkbox adds convenience for a very niche corner case, at worst it's yet more clutter in an already very "techy" interface that can confuse users. CCing Nate, I'm sure he'll have an opinion. Yeah, my impression is that this is the sort of thing where we should just make a decision to always do it, or never do it, but adding an option is not really very user-friendly. The kind of user who will know enough to actually check the checkbox is able to simply install the relevant packages manually. ... or just link to open popup with full list of items / packages. When I feed attachment 124353 [details] into drkonqi git master I get a MayBeUseful score (that is 2 out of 3 starts) and that is entirely sufficient for bug reporting, so while unfortunate that it can't reach 3 stars it really does not have any impact whatsoever on anything.
drkonqi(32202)/(org.kde.drkonqi.parser) BacktraceParser::calculateRatingData: Rating: 132 out of 144 Usefulness: MayBeUseful
With your specific stack trace it cannot ever be higher than that, and that has nothing to do with the other threads, they are entirely ignored for rating, as they should be.
What pulls down the score down are
#12 0x00007f632a53c5bc in ?? ()
#13 0x0000000000000000 in ?? ()
which are of course garbage frames nobody can do anything about.
So... that leaves us with the question of whether there should be a way to get all missing libraries. I am going to say no to this because the UI is already very full, specifically the backtrace widget. This is also not nearly as cheap to implement as it sounds. Because drkonqi only rates the crashed thread it doesn't even know that other symbols are also missing, so we'd have to first parse all lines for usefulness which requires refactoring of the rating system to become stateless. Overall too much time investment for too little gain IMO.
If someone wants to work on something like this, I would instead suggest to build a CLI tool on top of the existing code that you can feed a backtrace, or perhaps even a bug number/attachment number, and it will spit out a list of packages you'd need to install to get a complete backtrace. Or it could also just install them I suppose. That'd be loads more flexible WRT use cases and could also easily be exposed in the UI should we choose to find it valuable enough in the future.
|