Hi, There seems to exists inconsistency in CTFTraceReader timestamps.
* getStartTime() returns a raw timestamps * A call to getEndTime() after object instantiation returns a raw timestamps equals to start. * After reading an event, getEndTime() returns the timestamps + offset of the trace. When start has no offset, this leads to a funny result: duration = end - start = ~42 years (2012 - 1970) Also, a seek should be performed with a timestamps relative to start, not (start + offset). Thus, reader.seek(reader.getEndTime()) if done after object instantiation returns the first event in the trace, and if done after goToLastEvent(), returns a null event, because of the offset. I would suggests that timestamps getters should all adds offset or not, and that seek should follow the same convention by accepting timestamps returned by getStartTime() and getEndTime(). On a side note: goToLastEvent() is very not efficient, because all events in the trace is processed to reach the end. Could it be possible to directly jump to the end instead? Cheers, Francis
smime.p7s
Description: Signature cryptographique S/MIME
_______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
