dicksites / KUtrace

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.
Other
625 stars 56 forks source link

Spantotrim labels filtering bug #6

Open wagler opened 7 months ago

wagler commented 7 months ago

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'.