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:[email protected]]
Sent: Thursday, March 05, 2015 12:02 PM
To: Neil Bryan
Cc: [email protected]<mailto:[email protected]>
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
<[email protected]<mailto:[email protected]>> 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@meteorubuntu-OptiPlex-7010:/data/nbryan/Meteor/altera_trace$ babeltrace
--help
BabelTrace Trace Viewer and Converter 1.0.0-rc1
nbryan@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
[email protected]<mailto:[email protected]>
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
_______________________________________________
lttng-dev mailing list
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
