Low-overhead tracing of all Linux kernel-user transitions, for serious performance analysis. Includes kernel patches, loadable module, and post-processing software. Output is HTML/SVG per-CPU-core timeline that you can pan/zoom down to the nanosecond.
I believe there's a bug in spantotrim's detection of span endpoints, when filtering by label.
If you run cat some_span_file.json | ./spantotrim label, it should extract and output the span of events between the label and /label-marked events.
However, if your filter label is less than 6 characters, it doesn't stop when it reaches /label
It keeps going, copying everything from the label event all the way to the last event in the original span file.
The bug is in this block of code around line 94 in spantotrim.cc:
if ('9' < argv[1][0]) {
// Does not start with a digit. Assume it is a label and
// that we should filter
// Mark_abc label .. Mark_abc /label
// inclusive
int len = strlen(argv[1]);
if (len > 6 ) {len = 6;}
memcpy(label, argv[1], len + 1);
memcpy(notlabel + 1, label, len);
notlabel[0] = '/';
notlabel[7] = '\0'; <------------------------the bug is here
When it sets up the notlabel string, it assumes label was exactly 6 chars, so it hard-codes notlabel's null-terminator byte to be in index 7. However, if the label was less than 6 characters, then the null-terminator byte would need to come earlier than index 7 in notlabel. If we keep it at index 7, then the gap between the real end of the string and the null-terminator will be filled with random values. I think these random values are causing the notlabel string comparison to fail, when checking the event marker labels around line 151:
if (strcmp(notlabel, temp) == 0) {next_inside_label_span = false;}.
notlabel[7] = '\0'; should be replaced with notlabel[len+1] = '\0'.
I believe there's a bug in spantotrim's detection of span endpoints, when filtering by label. If you run
cat some_span_file.json | ./spantotrim label
, it should extract and output the span of events between thelabel
and/label
-marked events. However, if your filter label is less than 6 characters, it doesn't stop when it reaches/label
It keeps going, copying everything from thelabel
event all the way to the last event in the original span file.The bug is in this block of code around line 94 in spantotrim.cc:
When it sets up the
notlabel
string, it assumeslabel
was exactly 6 chars, so it hard-codesnotlabel
's null-terminator byte to be in index 7. However, if the label was less than 6 characters, then the null-terminator byte would need to come earlier than index 7 innotlabel
. If we keep it at index 7, then the gap between the real end of the string and the null-terminator will be filled with random values. I think these random values are causing thenotlabel
string comparison to fail, when checking the event marker labels around line 151:if (strcmp(notlabel, temp) == 0) {next_inside_label_span = false;}
.notlabel[7] = '\0';
should be replaced withnotlabel[len+1] = '\0'
.