I am trying to do some profiling of one of the third part tool I am likely
to use for which I do not have source code.
I tried to run it using time command and later with strace.
I noticed that system time reported by time is o where close to the sum of
the system call times reported stace.
Of course I have many read and write calls.
So here are my questions.
Does strace includes IO wait time in the timing reported in read?
And I presume time command does not and hence timing reported by time and
strace are completely skewed
Any help will be appreciated
This may be a known bug, but I've noticed that running strace with -i
("print instruction pointer at time of syscall") can result in a failed
upeek() call at the very beginning:
# strace-4.5.6/strace -i /bin/ls
upeek: ptrace(PTRACE_PEEKUSER,12475,48,0): No such process
[????????] execve("/bin/ls", ["/bin/ls"], [/* 46 vars */]) = 0
I haven't seen this problem under i386/Linux 2.6.x, but it happens
frequently under 2.4.x (and also under CRIS/Linux).
What happens is that when fake_execve() is called, the child process may
or may not have stopped (it stops as a result of execve). If it hasn't
stopped then obviously you can't do PTRACE_PEEKUSER. But with -i, strace
tries to read the PC anyway causing the failed upeek().
Actually, I don't think strace should be trying to read the PC here in the
first place. Printing the PC for the initial execve syscall doesn't seem
very useful to me.