[Gammaray-interest] Thoughts about the problem scanner

[Christian Gagneraud]

On Thu, 7 Mar 2019 at 10:43, Volker Krause <volker.krause at kdab.com> wrote:
> > 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.

Well, there's a big piece missing, how to automatically interact with
the GUI. Something provided by Squish, but not Gammaray.
I still have an experimental branch somewhere, where i tried to add
query capability, but in all honesty, it's unlikely i'll work on that
any time soon.
Still, i'll keep this idea in mind. Maybe a simple solution could be
found (eg, maybe run a javascript that has access to the object model,
and can call slots...)

>
> > 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 :)

But i'm very interested in that feature, binding cascading was what i
actually had in mind. I have a use case where we have lot of direct
connections, where several threads are involved, and i'm highly
suspecting that chains of signal/slots connections cross several
threads, and maybe even end up in the original thread.

So I started to look at that, didn't do much so far.
I found the {Abstract|Inbound|Outbound}ConnectionsModel, and the
SignalHistoryModel. Am I missing more data sources?
I haven't look at the SignalHistoryDelegate/View, but i guess that's
where i'll find out how to deduce the weighting edges you described
above.

IMHO, some models should contains these dynamic data in a more
processed way, eg AbstractConnectionsModel contains static data, while
SignalHistoryModel contains "raw" dynamic data, eg. start/end time (of
the connect/disconnect?). no start/stop at the event level (?!?), no
trigger counter, no accumulated process time, ...

So Am I right that to get that started, i would first need to enhance
the SignalHistoryModel?
I don't see the point to do all the tracking/calculation in the GUI
part, or in another (new) class or I will end up duplicating code from
the signal history view.

Thanks,
Chris

>
> Regards,
> Volker