Bug 418538 - Only check Akonadi duplicates on KDEPIM bug reports
Summary: Only check Akonadi duplicates on KDEPIM bug reports
Status: RESOLVED FIXED
Alias: None
Product: drkonqi
Classification: Applications
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-06 12:23 UTC by Christoph Feck
Modified: 2021-07-09 09:24 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Feck 2020-03-06 12:23:07 UTC
STEPS TO REPRODUCE
Check suggested duplicates of bug 417435 (also seen on many other bugs)

OBSERVED RESULT
DrKonqi suggests mostly unrelated duplicates from Akonadi. It seems it has a limit of duplicates, and thus probably discards related duplicates.

EXPECTED RESULT
DrKonqi could make an effort to only check Akonadi duplicates when reporting bugs against Akonadi, KMail2, or other Kontact applications. For the rare cases where a different KDE application uses Akonadi (e.g. digiKam), the bug triaging team could infer related to Akonadi from the backtrace.
Comment 1 Harald Sitter 2020-03-13 13:56:16 UTC
I may be misremember but I'm somewhat certain that the existing mappings file already allows for the definition of a group and that group would be used to limit the search. Have you had a look at the mappings file?

The problem of course is that these files do go out of date and are poorly maintained, so I am not surprised if it is broken or outdated.

Also, I think the example bug particularly is more a symptom of bugs elsewhere. For one the backtrace rating probably has gone wrong. To rate a backtrace drkonqi will look at the signalling thread and try to rate the value of each line, since half the lines there do not even have any symbols that crash shouldn't have been anywhere near reportable. And secondly to find dupes drkonqi searches for (I think) the first fully resolved frame so probably 'PackageKit::Transaction::finished' which doesn't even appear in the potential dupes it found, meaning something may also be wrong with the search :|
Comment 2 Harald Sitter 2020-03-13 14:42:47 UTC
https://phabricator.kde.org/D28026 & https://phabricator.kde.org/D28027

I cannot actually reproduce the dupe search having gone wrong in such a phenomenal fashion. As search term it should have used 'PackageKit::Transaction::finished' which isn't even in any of the listed dupes in that example bug, so I'm gonna consider that a fluke in lieu of reproducibility.

As for the actual request here: This is indeed already supported in the mappings file and you'd just need to set this up properly. I ultimately think the particular root problem cannot happen with working line parsing though. So, changing it may be unnecessary, I'll leave it up to you.
In the mappings file there are ProductGroup that define mappings from a product (e.g. apper) to BZGroups and BZGroups defines products that are part of that group. All products always have the kdeplatform group so that's how Akonadi ended up in the search. i.e. 
apper => autoinjected kdeplatform => apper also searches for dupes in kde|kdelibs|kio|kfile|Oxygen|solid|Phonon|Akonadi
Comment 3 Harald Sitter 2020-04-06 13:46:20 UTC
Git commit dd180bb4d057b7147c07beedd78d64b671498e40 by Harald Sitter.
Committed on 06/04/2020 at 13:43.
Pushed by sitter into branch 'Plasma/5.18'.

further constrict line parsing of .so files

Summary:
As seen in https://bugs.kde.org/show_bug.cgi?id=417435 the previous fix
for .so detection actually falls flat on the face for most things
other than glib2. The original test here was flawed as libglib-2.0.so.0
has the complete suffix '0.so.0' which matched the original parsing
condition. most libraries however are libfoo.so.0 and for that the suffix
would be 'so.0' which did not match the original condition.

extend the condition to properly cover files without so-version, files with
awkward suffix (such as glib) and files with normal names and normal
versioning.
also extend test case accordingly

Test Plan: test passes. all lines from 417435 score less than `Good`

Reviewers: cfeck, ngraham

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D28026

M  +5    -1    src/parser/backtraceparsergdb.cpp
M  +37   -7    src/tests/gdbbacktracelinetest.cpp

https://commits.kde.org/drkonqi/dd180bb4d057b7147c07beedd78d64b671498e40
Comment 4 Harald Sitter 2020-04-06 13:47:37 UTC
Git commit 113b91bfee13caa9590b1d029783db37a6783a52 by Harald Sitter.
Committed on 06/04/2020 at 13:46.
Pushed by sitter into branch 'Plasma/5.18'.

fix line rating for new format when function name is missing

Summary:
previously this supposedly was

`#2  0x00007fefe9ef79e8 in ?? () at /usr/lib/dri/i965_dri.so`

nowadays the ?? is simply empty. the rating mechanism wasn't properly
handling this. treat an empty function name to mean the same as ?? and
rate the line as MissingFunction/Everything depending on whether
libraryName is also missing.

also update test expectations accordingly (could have actually seen that
discrepancy if one had paid attention to the outcoming rating :S)

Test Plan:
test passes. most lines from 417435 now rate `MissingFunction` and the whole trace is considered useless

```
Rating: 128 out of 364 Usefulness: Useless
90%: 327.6 70%: 254.8 40%: 145.6
```

Reviewers: cfeck, ngraham

Reviewed By: ngraham

Subscribers: ahmadsamir, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D28027

M  +2    -2    src/parser/backtraceparsergdb.cpp
M  +4    -4    src/tests/gdbbacktracelinetest.cpp

https://commits.kde.org/drkonqi/113b91bfee13caa9590b1d029783db37a6783a52
Comment 5 Harald Sitter 2021-07-09 09:24:18 UTC
Git commit ce1a3326fe42014417a895aaf2a4ea45ab51b7bf by Harald Sitter.
Committed on 09/07/2021 at 09:23.
Pushed by sitter into branch 'master'.

update kdeplatform

half the stuff in the list never was a platform kind of dependency that
would be used by most or all apps.
the other half is from kdelibs4 times.

replace the lot with kcoreaddons. it's realistically the only worthwhile
platform dependency we can expect. while an app could get by without it,
it'd not have kcrash support cause currently kcrash only sends us the KDE
bug address when it finds kaboutdata and kaboutdata are in kcoreaddons.

technically I suppose the more appropriate replacement for kdelibs would be
to list all the frameworks, but ultimately that would bring down performance
and be a lot of work (or require refactoring to how the mappings work).
all in all not worth it.

M  +1    -1    src/data/mappings

https://invent.kde.org/plasma/drkonqi/commit/ce1a3326fe42014417a895aaf2a4ea45ab51b7bf
Comment 6 Harald Sitter 2021-07-09 09:24:26 UTC
Git commit 5b5a0b6c4c127984fb4318f45b7e9aeaf609b224 by Harald Sitter.
Committed on 09/07/2021 at 09:23.
Pushed by sitter into branch 'master'.

add akonadi to the kdepim mapping groups

akonadi previously lived in the kdeplatform but realistically never was
nearly as wide spread as that would indicate. since kdeplatform was
updated and shrunk, let's add akonadi to the kdepim groups so it gets
searched for dupes on topically relevant products

M  +2    -2    src/data/mappings

https://invent.kde.org/plasma/drkonqi/commit/5b5a0b6c4c127984fb4318f45b7e9aeaf609b224