GitLab

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)

CCBUG: 418538

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

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

CCBUG: 418538

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

Summary:
for unknown reasons gdb seems to behave inconsistently here. usually
'at' denotes a file, but there are backtraces where it doesn't
e.g. https://bugs.kde.org/show_bug.cgi?id=416923

I've add a trivial suffix check to ensure parsing of these lines works
correctly even when 'at' is used in combination with a library name.

this is a bit hackish, but in reality this entire parsing tech should
probably be replaced by a python plugin for gdb so we can get interactive
access to the frames and serialize them in a well defined format instead of
having to parse "random" text

on top of that our regex assumed we'd always have a function name, which is
also not true as that bug report shows. to mitigate this the matching group
has been made optional.

this commit also adds a test for the gdb line parsing unit with some
obvious line samples I could find just now

Test Plan: all tests pass

Reviewers: ngraham

Reviewed By: ngraham

Subscribers: ngraham, plasma-devel

Tags: #plasma

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

Minor optimization.
Assign parent directly

This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
techbase wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:

http://community.kde.org/Frameworks/GitOldHistory

If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.

Branched from the monolithic repo kde-runtime, frameworks  branch, at commit
85b1a18736650e28d8addd441f83083987298233