[lttng-dev] LTTng 2.6.0: Corrupt metadata?

[Glen Keane]

Hey Neil,

I hope that this helps you!

The start of the lttng metadata file will start with some binary data if it
is generated by a tracing session, The binary correlates to a 32 bit magic
number, a uuid, with 16 sections of 8 bit ints, a 32 bit checksum, a 32 bit
content size, a 32 bit packet size, some 8 bit ints representing the
compression scheme, the encryption scheme, the checksum, the major release
number of the Common Trace Format(CTF) in use and the minor release number
of the CTF in use.

Everything after that binary data is the textual representation of the CTF
metadata, which is sent in packets, I think. The "corrupt" areas you see in
the text is the end of a packet that was created by lttng and start of a
new packet that was created by lttng, again, I think, I'm not an expert on
this part of the CTF. I know that the start of the CTF metadata can have
the binary I described, however.

Its all part of the CTF, the guys pointed me to this on their IRC channel,
maybe it could help you?

http://diamon.org/docs/ctf/v1.8.2/

Sorry I rambled, I enjoy the theory behind the CTF! :D

The segmentation fault is still an issue though. :(

On Thu, Mar 5, 2015 at 10:50 AM, Neil Bryan <Neil.Bryan at ttp.com> wrote:

>  Hello LTTng devs,
>
>
>
> I am experiencing a strange problem with what I believe is corrupt
> metadata. This is seen on v2.6.0 of LTTng.
>
>
>
> If I try and parse recovered traces using Babeltrace, it fails with a
> segmentation fault.
>
>
>
> nbryan at meteorubuntu-OptiPlex-7010:/data/nbryan/Meteor/altera_trace$
> babeltrace --help
>
> BabelTrace Trace Viewer and Converter 1.0.0-rc1
>
>
>
> nbryan at meteorubuntu-OptiPlex-7010:/data/nbryan/Meteor/altera_trace$
> babeltrace auto-20150304-091109/
>
> Segmentation fault (core dumped)
>
>
>
> I thought it may be worth a look at the metadata file and I observed the
> following (these are just three examples):
>
>
>
> Environment:
>
> env {
>
>      hostname = "socfpga_cyclone5";
>
>      domain = "kernel";
>
>      sysname = "Linux";
>
>      kernel_release = "3.10.31-ltsi-05035-g801a40f";
>
>      kernel_version = "#3 SMP Tue Mar 3 17:31:45 GMT 2015";
>
>      tracer_name = "lttng-modules";
>
>      tracer_major = 2;
>
>      tracer_minor = 6;
>
>      tracer_patchlevel = 0;
>
> };
>
>
>
> event {
>
>      name = "syscall_exit_recvmmsg";
>
>      id = 921;
>
>      stream_id = 0;
>
>      fields := struct {
>
>            integer { size = 32; align = 32; signed = 1; encoding = none;
> base = 10; } _ret;
>
>            integer { size = 32; align = 32; signe   WСu?­©)2ѕИN№d™Џ‰n®
> и   Ђ     d = 0; encoding = none; base = 16; } _mmsg;
>
>            integer { size = 32; align = 32; signed = 0; encoding = none;
> base = 16; } _timeout;
>
>      };
>
> };
>
>
>
> Decoded binary values:
>
>
> 00h,00h,00h,57h,1Dh,D1h,75h,3Fh,ADh,A9h,29h,32h,BEh,C8h,4Eh,B9h,64h,99h,8Fh,14h,89h,6Eh,AEh,00h,00h,00h,00h,E8h,7Fh,00h,00h,00h,80h,00h,00h,
>
> 00h,00h,00h,01h,08h
>
>
>
> event {
>
>      name = "syscall_exit_getcpu";
>
>      id = 903;
>
>      stream_id = 0;
>
>      fields := struct {
>
>            integer { size = 32; align = 32; signed = 1; encoding = none;
> base = 10; } _ret;
>
>            integer { size = 32; align = 32; signed = 0; encoding = none;
> base = 16; } _cpup;
>
>            integer { size = 32; align = 32; signed = 0; encoding = none;
> base = 16; } _nodep;
>
>            integer { size = 32; align = 32; signed = 0; encoding = none;
> base =   WСu?­©)2ѕИN№d™Џ‰n®    и   Ђ      16; } _tcache;
>
>      };
>
> };
>
>
>
> Decoded binary values:
>
>
> 00h,00h,00h,57h,1Dh,D1h,75h,3Fh,ADh,A9h,29h,32h,BEh,C8h,4Eh,B9h,64h,99h,8Fh,14h,89h,6Eh,AEh,00h,00h,00h,00h,E8h,7Fh,00h,00h,00h,80h,00h,00h,00h,
>
> 00h,00h,01h,08h
>
>
>
> event {
>
>      name = "syscall_exit_fstatat64";
>
>      id = 886;
>
>      stream_id = 0;
>
>      fields := struct {
>
>            integer { size = 32; align = 32; signed = 1; encoding = none;
> base = 10; } _ret;
>
>            integer { size = 32; align = 32; signed = 1; encod
> WСu?­©)2ѕИN№d™Џ‰n®    и   Ђ     ing = none; base = 10; } _dfd;
>
>            string _filename;
>
>            integer { size = 32; align = 32; signed = 0; encoding = none;
> base = 16; } _statbuf;
>
>            integer { size = 32; align = 32; signed = 1; encoding = none;
> base = 10; } _flag;
>
>      };
>
> };
>
>
>
> Decoded binary values:
>
>
> 00h,00h,00h,57h,1Dh,D1h,75h,3Fh,ADh,A9h,29h,32h,BEh,C8h,4Eh,B9h,64h,99h,8Fh,14h,89h,6Eh,AEh,00h,00h,00h,00h,E8h,7Fh,00h,00h,00h,80h,00h,00h,
>
> 00h,00h,00h,01h,08h
>
>
>
> In a metadata file containing 7200 lines, I see this corruption 74 times.
>
>
>
> I also notice that the header of the metadata file contains something very
> similar:
>
>
>
>
> 57h,1Dh,D1h,75h,3Fh,ADh,A9h,29h,32h,BEh,C8h,4Eh,B9h,64h,99h,8Fh,14h,89h,6Eh,AEh,00h,00h,00h,00h,D8h,27h,00h,00h,00h,80h,00h,00h,00h,00h,00h,01h,08h
>
>
>
> This appears identical to the other instances, less the first three 00h
> bytes.
>
>
>
> Now it may be intentional to squirt binary data into what is essentially
> a text file, but it looks suspicious. Can anyone shed any light on what is
> happening here?
>
> Is the metadata file supposed to have any binary data in it at all?
>
>
>
> Thanks,
>
>
>
> Neil.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20150305/f64b98e0/attachment.html>