Data corruption when using `printf` and/or `if` on an associative-array map about bpftrace

[dkogan]

This fixes both the simple reproducer in this report AND the bigger script that I was having trouble with originally. Thank you!

It sounds like #3195 is a workaround and not a fix, so I'll let yall close this bug report when you feel it's ready.

[janet-campbell]

This looks to solve a long-standing issue I've had where data would make it into some maps but not others. This is a great find.

[ajor]

There's definitely a bug here, thanks for finding it!

There are a couple of different problems which I think we can separate.

Problem 1 - Overly high latencies

At first glance, I don't think this one is actually a bpftrace bug. Your script isn't handling the case where multiple openat system calls could be happening in parallel on different threads/CPUs.

The solution is to use tid as a key in every map access so that multiple threads don't stomp on each other's data:

tracepoint:syscalls:sys_enter_openat
{
  $key = str(args->filename);
  @keymap[tid] = $key;

  @t[tid, $key] = elapsed;
}

(This might also fix the second problem, but that's just down to the luck of compiler optimisations)

Problem 2 - variable lifetime analysis bug

The missing value for $key after the if statement is a real bpftrace bug. We're not correctly calculating the lifetime of the $key variable so the optimiser thinks it's dead too early and overwrites its memory.

Technical details for future reference: we're inserting two lifetime.end instructions for the same variable. I think this is likely the same issue as #3000. Looking at the common patterns between the two issues, it might be using variables in map-keys that is the problem.

[ajor]

Confirmed this is the same issue as #3000. I've also tested your script with the fix in #3195 and the data for $key looks good.

[ajor]

It sounds like #3195 is a workaround and not a fix, so I'll let yall close this bug report when you feel it's ready.

I think that fix is as good as we'll be getting in the near future - it's the same approach that we were already taking elsewhere in code generation, we'd just missed this spot. Closing.