[lttng-dev] LTTng 2.6.0: Corrupt metadata?

Neil Bryan Neil.Bryan at ttp.com
Thu Mar 5 08:39:08 EST 2015 

Hi Glen,

Thank you for the response. I have taken the binary data prepended to the textual packet data and using the link you provided, found this structure:

struct metadata_packet_header {
    uint32_t magic;              /* 0x75D11D57 */
    uint8_t  uuid[16];           /* Unique Universal Identifier */
    uint32_t checksum;           /* 0 if unused */
    uint32_t content_size;       /* in bits */
    uint32_t packet_size;        /* in bits */
    uint8_t  compression_scheme; /* 0 if unused */
    uint8_t  encryption_scheme;  /* 0 if unused */
    uint8_t  checksum_scheme;    /* 0 if unused */
    uint8_t  major;              /* CTF spec version major number */
    uint8_t  minor;              /* CTF spec version minor number */
};

This helped decode the binary data and I came up with the following:

57h,1Dh,D1h,75h, -> 0x75D11D57 magic number

3Fh,ADh,A9h,29h,32h,BEh,C8h,4Eh,B9h,64h,99h,8Fh,14h,89h,6Eh,AEh, -> UUID

00h,00h,00h,00h, -> Checksum
D8h,27h,00h,00h, -> 0x000027D8  1020d Content Size (bits)
00h,80h,00h,00h, -> 0x00008000  2048d Packet size (bits)
00h, compression -> none
00h, encryption  -> none
00h, checksum scheme -> ?
01h, -> CTF major version
F0h  -> CTF minor version

So the mystery regarding the binary data at the start of the metadata is solved.

What is still confusing is why this should appear again and again in the body of the text-part of the metadata.

Regards,

Neil.


From: Glen Keane [mailto:glenkeane.94 at gmail.com]
Sent: Thursday, March 05, 2015 12:02 PM
To: Neil Bryan
Cc: lttng-dev at lists.lttng.org<mailto:lttng-dev at lists.lttng.org>
Subject: Re: [lttng-dev] LTTng 2.6.0: Corrupt metadata?

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<mailto: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<mailto: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/953ecbf3/attachment-0001.html>

More information about the lttng-dev mailing list