Can't trace some system call in multi-thread program about tracee

[yanivagman]

Hi @chae-yc ,

Thanks for opening this issue.
Indeed in master there was a bug that forks (or clones) of a taced process were not traced as well, and this is why it didn't show any event (other than the parent pid events) in master branch.
I opened a PR for this issue: #224

I also checked your program, and saw that when the number of events was small (~100,000), there was no issue.
When I changed to 1M events, I reproduced the issue you reported.
I then decided to check with a bigger buffer by running with '-b 4096':
sudo ./tracee -b 4096 -e getpid

And indeed no events lost this time!

I suspect there is an issue with the reported number of lost events.
I'll try to figure this out, but I'm not sure this issue is related to Tracee itself (hopefully it is, and then we can fix it quickly :-) )

As the example you gave calls syscalls in a loop, the buffer will be filled quickly, thus should be big enough. Please use a bigger buffer like suggested above if you need to support this kind of scenarios (bare in mind this means more memory consumption by Tracee)

[yanivagman]

Regarding the lost events...

Waiting few extra seconds (~10sec) after all events were printed (using the default buffer, without '-b 4096'), I can see that all 1M events are either printed (~350K events) or lost (~650K events). If I exit Tracee before waiting this time, there are missing lost events like reported. So, there is no bug here for the lost events count...

Tracee gets the lost events count from gobpf (using lost channel), and this, in turn, comes from the kernel - either one of these may cause this delay of reporting lost events.