public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Mark Geisert <mark@maxrnd.com>
To: cygwin@cygwin.com
Subject: Re: long I/O delays when strace is running
Date: Sat, 22 Apr 2017 15:24:00 -0000	[thread overview]
Message-ID: <58FA83DB.3000209@maxrnd.com> (raw)
In-Reply-To: <7d56e728-32a3-9179-b002-e83880e297d0@pobox.com>

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.

..mark


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  reply	other threads:[~2017-04-21 22:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-20 18:13 Daniel Santos
2017-04-21  0:11 ` Gluszczak, Glenn
2017-04-21  7:57   ` Daniel Santos
2017-04-21  9:38     ` Daniel Santos
2017-04-21 11:06       ` Daniel Santos
2017-04-21 12:08         ` Mark Geisert
2017-04-21 18:23           ` Daniel Santos
2017-04-22 15:24             ` Mark Geisert [this message]
2017-04-23 12:58               ` Daniel Santos
2017-04-23 18:15                 ` Mark Geisert
2017-04-24  8:23                   ` Daniel Santos
2017-04-24  9:24                   ` Daniel Santos
2017-04-24  9:34                     ` Mark Geisert
2017-04-24 15:00                       ` Daniel Santos
2017-04-24 19:30                       ` Daniel Santos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58FA83DB.3000209@maxrnd.com \
    --to=mark@maxrnd.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).