dtrace vs. truss for # of syscalls

J

jb82

Very simple question. Why the discrepancy between dtrace and truss?

Code: 
jb@p1 ~> doas dtrace -n 'syscall:::entry /execname == "zstd"/ { @[probefunc] = count(); }' -c 'zstd -b'
dtrace: description 'syscall:::entry ' matched 1612 probes
 3#Lorem ipsum       :  10000000 ->   2987328 (x3.347),  236.9 MB/s, 1102.1 MB/s
dtrace: pid 6615 has exited

  exit                                                              1
  fstat                                                             1
  ioctl                                                             1
  mprotect                                                          1
  madvise                                                           3
  mmap                                                              4
  write                                                             9

on the other hand, truss reports many more syscalls for zstd -b. Why so? Is it that dtrace does not count the loader, or it's more involved/non-deterministic?
 
Can you post-process truss output and show its stats in the similar format?
BTW, you can also try ktrace + kdump.

Finally, the idiomatic DTrace condition for this kind of tracing is /pid == $target/.
 
Having said that, the difference is most probably related to what the tools consider to be the start of the traced process.
The process creation / startup is a complicated affair.

See description of evaltime dtrace option.
Note that in the past I had trouble using some of possible values on FreeBSD, dtrace simply wouldn't attach to a process.
Yeah, see PR 278489
 
Valgrind with the option —tool=none —trace-syscalls=yes is another possibility. Syscall tracing is more intended for testing Valgrind rather than user tracing but it should work fairly well. Make sure there are no syscall errors with memcheck first though.
 
You must log in or register to reply here.
Back
Top