-
Notifications
You must be signed in to change notification settings - Fork 71
Description
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'.