This is the mail archive of the
mailing list for the Cygwin project.
Re: long I/O delays when strace is running
Daniel Santos wrote:
Thanks for the help Mark. My current suspicion is that the _pinfo isn't getting
initialized when the process is exec-ed by strace, but I haven't proved that. I
added a dump() member function to _pinfo, but it crashes and I can't seem to
debug that in gdb (it makes a stacktrace file instead of letting me debug). So
the cygpid.<n> shared object is there, but I'm suspecting that it's either all
zeros or just not fully initialized -- and this is for the pid of the strace
process. So for each strace process, there's a 2-3 second delay when trying to
read the process list.
Re debugging strace itself, you may not realize that strace is not a
Cygwin-native program. It's a Windows-native program. So debugging it with
Cygwin gdb is problematic.
I can tell you roughly how strace operates. It launches the target program with
CreateProcess(), not with exec(). It acts as the debugger of the target in
order to receive Windows DEBUG_EVENTs for things like DLL loads, thread
creation, etc. etc. The Cygwin DLL in the target can tell when it's being run
under strace and generates trace lines with OutputDebugString() calls that
strace receives as DEBUG_EVENTs. strace then just outputs the trace line.
strace does have to explicitly ContinueDebugEvent() on each DEBUG_EVENT it
receives, and if there's some issue with that then the target program will
remain suspended awaiting that continue. I've never seen an issue with this but
it's another possible place to look, I suppose.
Why strace appears to interact badly with /proc accesses, I have no idea.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple