[Gammaray-interest] Thoughts about the problem scanner

[Volker Krause]

On Tuesday, 19 March 2019 14:29:53 CET Christian Gagneraud wrote:
> 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...)

Right, if there is no other way to put the application into a state you want 
to scan (like loading a data set or triggering some processing via a command 
line switch), that is needed too indeed. And yes, that's a very big subject.

> > > 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.

Yes, I don't think we have the data needed for this in the right form already.

There's two sources of data available I think:
- connections: Unlike in Qt4 we don't have hooks to be notified about 
connects/disconnects anymore, so we can only list connections on demand for a 
given object. That's what the xConnectionModel classes do, as well as the 
connection issue scanner. That's also the reason why we have no model 
available anymore with all existing connections.
- signal emissions: For those we have very high level of detail hooks (begin/
end signal emission, begin/end slot invocation), which is what the signal 
history model collects.

The signal history model is already quite expensive, you certainly don't want 
to transfer that entirely to the client just to sum up costs for example, so 
doing aggregation in there makes a lot of sense. A useful intermediate step to 
verify the data is all there might be to show emission data in the connections 
tab of an object.

However, If you primarily care about the connection structure rather than the 
emission data, producing a graphviz dot file with code similar to the 
connection issue scanner should already be doable, maybe with some filtering 
applied to hide non-connected objects to keep the result readable.

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/20190320/7e745992/attachment.p7s>