[ltt-dev] Babeltrace timestamp problem

Simon Marchi simon.marchi at polymtl.ca
Thu Aug 11 09:08:38 EDT 2011


Hello,

I think there may be a little problem with the accuracy of the
timestamps read by babeltrace.

Here is what I did:

(code available here, if you want it
http://git.dorsal.polymtl.ca/~smarchi?p=babeltrace.git;a=shortlog;h=refs/heads/timestampdebug)

1- Hijack the ctf_update_timestamp function in ctf.c so that we log in
a file all the timestamp that are read from the CTF format.

2- Have the dummy output format output log the timestamp of all
"written" events in an other file.

3- Sort the output of #1 (with coreutils sort), because at this point
they do not come out sorted.

4- Compare both. They should be identical, but they are not.

I compared a similarly formatted output of the Java parser, and it is
identical to the file of #1.

I noticed that the differences often look like this:

@@ -368,10 +368,10 @@
 248813704165405
 248813704165482
 248813704166130
-248813704166315
 248813704169065
 248813704169935
 248813704170150
+248813704170150
 248813704171110
 248813704171937
 248813704176084
@@ -400,7 +400,7 @@
 248813704252089
 248813704252267
 248813704253474
-248813704254629
+248813704255344
 248813704255344
 248813704255859
 248813704256404

where a good timestamp (the minus in the diff) is overwritten by a
later timestamp (the plus in the diff). Sometimes, like in the first
example, they (the timestamp that gets overwritten and the timestamp
that overwrites) are not contiguous at the trace level, but every time
I checked, they were next to each other at the stream (file) level. So
that means the problem is probably somewhere in the handling of
ctf_stream.timestamp.

Simon




More information about the lttng-dev mailing list