I'm using dtrace to profile a C++ program (It's SRS in case it matters) based on State Threads, a goroutine-like library for writing concurrent C++ code.
The command I use:
dtrace -n 'profile-199 /pid == '$PID'/ { @[ustack(100)] = count(); } tick-15s { exit(0); }' -o $OUTPUT_FILE &>/dev/null
The sampling output and the flame graph shows the majority of CPU time is spent on "State Threads"'s _st_kq_dispatch function, and the corresponding call stack is like
_st_kq_dispatch
_st_idle_thread_start
_st_thread_main
st_thread_create
st_usleep
...
which is next to useless by not revealing anything about execution of user functions. However if profiled with macOS's builtin /usr/bin/sample, the result is as expected. So what's wrong with my dtrace usage here? What is special about "State Threads" that makes it cannot be profiled using dtrace like other normal programs? (BTW System Integrity Protection is enabled on my macOS, is it a problem?)
