I made a patch to remove the deadlock in the histogram [1]. But since the trace has a faulty timestamp, I cannot guarantee the application behaves entirely correctly. I don't have any analyses other than statistics and histogram, which work fine now. So if you spot anything else that seems problematic with such a trace, let us know!
Hi Genevieve,
I updated our application to the last version of Trace Compass (5.3), and the issue is still there, but from now on I would be able to test patches.
Thank you,
Alexis
Hi Alexis,
So babeltrace detects it as a malformed trace? What is the exact output of babeltrace? Maybe it's simply something that we did not implement in Trace Compass yet.
Would you be allowed to share the trace with us?
On 3/31/20 10:00 AM, tracecompass developer discussions wrote:
To avoid analyzing events that are malformed, I would like to verify in the trace if there is any inconsistencies. But I’m struggling to find how to do that outside of trace compass source code, before any analysis are performed to avoid ending in a deadlock.
Do you know what I could use to do that ?
For now, you can first read the trace with babeltrace to make sure it is ok. But Trace Compass should be able to figure out. I'll try to fix the dealock you mention at least, thanks for providing the stack trace, I'll see what can easily be done. Can you test patches (ie running from Trace Compass sources) or do use one of the Trace Compass RCP? If so, which version of Trace Compass are you using? In any case, have you tried the latest version (5.3) to make sure the bug is still present?
Best regards,
Geneviève
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tracecompass-dev