Hi, On 14.06.2017 17:12, Mathieu Desnoyers wrote: > Can you provide a copy of the metadata file ? And ideally the data > streams too ? This would give us a better idea of what is happening. > > Do you perform kernel or user-space tracing ? Do you trace huge > sequences of bytes within your own tracepoints ?
I perform kernel traceing only, in this case limited to syscalls, sched*, block* and irq*. No user-space tracepoints. I didn't know the metadata file was plain text, I had a quick look into it and noticed corruption already, with random garbage data inserted all over the place. I'm surprised babeltrace didn't choke on the metadata already. I can not provide the data file as it has confidential data. Looking at it with a hex editor, I see the same kind of garbage as in the metadata file, so both files are affected by the same problem. I've uploaded the metadata file to http://www.kdab.com/~thomas/stuff/metadata. To double-check that it isn't file system corruption, I ran "yes > test.data" - that file is OK, so it's probably a different problem. Any idea what can cause the corrupted trace? Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
