Skip to content
proctrace

Known Issues

It’s early days for proctrace and there’s a single ADHD-brained developer working on it in their spare time. There’s going to be bugs.

Duplicate exec events

For some reason you may see duplicate short-lived exec events. This is likely a bug in what events are generated by the bpftrace script.

Earlier in development there was an issue where when you recorded some programs you would see a flurry of fork events. Long story short, the tracepoint:sched:sched_process_fork probe in bpftrace was how we were detecting forks (I mean it’s in the name after all), but this probe also fires when a new thread is created. The solution was to instrument the clone family of system calls and inspect the flags passed to the system call to determine whether the clone was creating a new thread or a new process.

There’s likely a similar issue with how we’re generating exec events.

Missing or wrong exec arguments

There is a bug in bpftrace (reported by me) that causes the facilities for printing arrays of strings (like argv) to just not do anything in some cases. This means that when we go to print the arguments to an exec system call, sometimes we just don’t get anything back. To mitigate this during a recording we also query /proc to look up the arguments. This works most of the time, but if a process is very short lived it may already have terminated before we can look up the arguments.

Oddly enough, depending on which source you get your arguments from, you might get different answers. Without having looked into the cause for the discrepancies, it’s not clear which ones to use. For the moment we simply choose the longer string in hopes that it contains more information. This isn’t always correct. For example, say you have the following script:

#!/usr/bin/env bash


/bin/echo "hello"
sleep 1
curl -X GET "http://example.com"

Recording the execution of this script via

$ proctrace record ... -- ./script.sh

You may see that the sleep 1 call gets replaced with a bash ./script.sh.

Truncated arguments in rendered Mermaid diagrams

Say that one of the commands executed in the process tree is

curl -X GET "http://example.com"

The Mermaid syntax doesn’t like that URL (I think because of the :) and will not display anything that comes after the :. The full argument is still in the recording, so you can look up the full thing if you need it.