[Gammaray-interest] Thoughts about the problem scanner

[Volker Krause]

Hi,

On Wednesday, 6 March 2019 17:59:24 CET Christian Gagneraud wrote:
> A few quick random thoughts, sorry for the "dump" style.
> 
> First thing first:
> Have you seen the PR "ObjectInspector: Add thread affinity checker"
> (https://github.com/KDAB/GammaRay/pull/538/)?
> What do you think? Do you like it? Could we add more scanners like that?

Yes, more checks like that make sense IMHO. The problem reporter is a fairly 
new development, there is still a lot more potential in it I think (as 
mentioned in your second point too). You should have gotten an email from 
Allen to pave the way for getting this integrated.

> Second:
> Wouldn't it be nice to run the problem scanner in an automated way?
> The idea would be to use gammaray as an automated dynamic-analyzer (as
> oppose to, eg, clang static analyser).
> To achieve that it would be nice to run an app under gammaray control,
> and tell gammaray to run the "scan for problems", report on stdout (or
> in a file), and then call QCoreApplication::quit().
> What i have in mind is to use that in a test/validation process,
> manual or automated.
> For example, We use blocking PR, if your PR doesn't pass some
> buildtime/runtime test, the PR cannot be merged. This could be used,
> for example, to check that no cross-thread signal/slot connections are
> introduced in a project (prevention is better than cure)

I like the idea, I'd not block PRs on it yet though, considering the current 
false positive rates ;-)

Practically this would probably need some kind of command line client to 
trigger the scans and print the result for consumption by a CI system. A bit 
of work, but shouldn't be particularly hard I think, we should have all the 
pieces for that.

> Third:
> I've been thinking about adding a new feature to the signal inspector.
> The ability to export a dot file that graph all the signal/slot
> connections b/w a set of objects.
> The idea would be to add a new action to the signal menu. From there
> the user select s the objects of interest, and then the graph is
> generated as a graphviz dot file.
> The graph would contains all connections b/w the set of objects, plus
> the objects that have a first degree connections with the original
> set.
> Ideally the graph would contains these information (might be optional):
> - QObject thread affinity (using graphviz cluster [1])
> - connection type (eg, using style or color)
> - signal/slot names

The signal inspector is indeed another area where we don't leverage all 
possibilities yet IMHO. The signal tracing data is more detailed than what we 
display there, we could gain quite a bit with better visualization and 
filtering capabilities I think, especially when combined with knowledge about 
connections. A graph-based visualization of signal or binding cascades would 
indeed be awesome, possibly also with weighting edges by how often they 
trigger or how long they took to process :)

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4664 bytes
Desc: not available
URL: <http://mail.kdab.com/pipermail/gammaray-interest/attachments/20190307/d2f04295/attachment-0001.p7s>