https://bugs.kde.org/show_bug.cgi?id=400386
--- Comment #15 from Harald Sitter <[email protected]> --- Right. So. What's going on there is that you somehow have foreign stuff installed in the form of /lib/x86_64-linux-gnu/libsnapd-glib.so.1 and snapd-glib.so.1, but they aren't coming from a deb, much less from a deb that is neon's or ubuntu's (which are the only ones that would generally have debug symbols). Consequently the tool can't resolve packages to install to improve the backtrace. There's nothing we can do there, in fact, I don't think we can even detect this any better. This is kind of going off on a tangent but that backtrace isn't of very good quality actually ;). When scoring a trace, drkonqi looks at the quality of each line in the crashing thread (the one at the bottom in your paste) and then additionally weights them how close they are to the origin of the crash. That is because in the frames closest to the crash is where things usually have gone wrong e.g. in your trace frame #6 is of poor quality (it lacks source file reference and line reference) and has a weight of 13, frame 7-9 are of the worst quality and contain no useful information whatsoever with a weight of 12-10. To put that into perspective the weight of these 4 frames is 46, the weight of the remaining frames is only 45: even though the other frames are of excellent quality they are less than half as impactful on the overall score. All in all the trace is probably at 1 star quality and very close to two stars (the fact that the first frame is somewhat useful pulls the score up quite a bit). And to get back to the original problem. The reason the top most frames score so poorly is because they are from the library that isn't from us or ubuntu so there are no debug symbols. I'll leave the bug open in case you find another example where resolution fails. This one at least wasn't our fault :) -- You are receiving this mail because: You are watching all bug changes.
