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.
Get latest updates about Open Source Projects, Conferences and News.