Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] Trace Compass XML state provider changing multiple states

Hi,

Just as a summary of this topic, I was able to do customization that suits my needs. I've described them under:

http://tooslowexception.com/analyzing-runtime-coreclr-events-from-linux-trace-compass/

Best,
Konrad Kokosa

-----Original Message-----
From: tracecompass-dev-bounces@xxxxxxxxxxx [mailto:tracecompass-dev-bounces@xxxxxxxxxxx] On Behalf Of Konrad Kokosa
Sent: Wednesday, August 2, 2017 4:27 PM
To: 'tracecompass developer discussions' <tracecompass-dev@xxxxxxxxxxx>
Subject: Re: [tracecompass-dev] Trace Compass XML state provider changing multiple states

Hi,

Thank you for the answer. I'm just doing pattern provider definition because I'll need it for statistics anyway. I have already achieved some success but I will probably return with questions. This tool is great but it needs to overcome a fairly sharp learning curve.

Best,
Konrad

-----Original Message-----
From: tracecompass-dev-bounces@xxxxxxxxxxx [mailto:tracecompass-dev-bounces@xxxxxxxxxxx] On Behalf Of Genevieve Bastien
Sent: Wednesday, August 2, 2017 3:18 PM
To: tracecompass-dev@xxxxxxxxxxx
Subject: Re: [tracecompass-dev] Trace Compass XML state provider changing multiple states

Hi Konrad,

As far as I know, this use case is not possible in the current implementation. Though I do remember having had a similar discussion with someone a while back... Was it Jean-Christian?

Anyway, a way you could work around this is to use an XML pattern instead of a state provider. See [1] for the documentation. You could write your state machine in such a way that there would be one scenario per thread and they would reach a state where one of the possible transition is

<transition event="suspend_event" cond="same_process" target="wait_resume" action="set_suspended" />


where target is the target state of the fsm, the action would be your current stateChange, with the difference that the tid (2131, 2135, etc) would be a value queried in the scenario, and the 'same_process'
condition would be as follow

<test id="same_process">
    <if>
        <condition>
            <stateValue type="eventField" value="procname" />
            <stateValue type="query">
                <stateAttribute type="constant" value="#CurrentScenario" />
                <stateAttribute type="constant" value="procname" />
            </stateValue>
        </condition>
    </if>
</test>


The constant #CurrentScenario in the state attribute represents where the current scenario's specific value are stored. For instance, you could store a tid value there and use it in the action, or in other conditions for this thread.

[1]
http://archive.eclipse.org/tracecompass/doc/stable/org.eclipse.tracecompass.doc.user/Data-driven-analysis.html#Defining_an_XML_pattern_provider

I hope this helps.

Best regards,
Geneviève


On 08/02/2017 03:53 AM, Konrad Kokosa wrote:
> I am defining a custom XML state provider. On a particular event, I 
> would like to change value not for a single attribute but for bunch of 
> them, something like:
> <eventHandler eventName="suspendEvent">
>     <stateChange>
>         <stateAttribute type="constant" value="Processes" />
>         <stateAttribute type="eventField" value="procname" />
>         <stateAttribute type="constant" value="Threads" />
>         <stateAttribute type="constant" value="*" />
>         <stateValue type="int" value="$SUSPENDED" />
>     </stateChange>
> </eventHandler>
> It looks good except that it does not work. It changes the value for 
> attribute <someprocessname>\*. I would like to change the value for 
> attributes <someprocessname>\2131, <someprocessname>\2135, 
> <someprocessname>
> \2137 and so on. Except for the count and value of threads, which are 
> known only during analysis. I wonder if it is even possible in current 
> XML state provider definition. XSD schema does not help here, unfortunately.
>
> Best regards,
> Konrad Kokosa
>
>
>
> _______________________________________________
> tracecompass-dev mailing list
> tracecompass-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit 
> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev

_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/tracecompass-dev



_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/tracecompass-dev





Back to the top