public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Daniel Santos <daniel.santos@pobox.com>
To: cygwin@cygwin.com
Subject: Re: long I/O delays when strace is running
Date: Sun, 23 Apr 2017 12:58:00 -0000	[thread overview]
Message-ID: <a4afe377-3b4f-8373-8116-e812a8d82fbe@pobox.com> (raw)
In-Reply-To: <58FA83DB.3000209@maxrnd.com>


On 04/21/2017 05:12 PM, Mark Geisert wrote:
>
> 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

Well thank you, I wish I had read this earlier. I've been trying to 
debug (with gdb) strace (following children) and now I know why the 
debugger is blowing through breakpoints, because I may be debugging 
strace, but strace debugging it's own child.  I added a _pinfo::dump () 
member function that I'm calling from pinfo::init () after the test "if 
(!created && !(flag & PID_NEW))" and it's crashing because for some 
processes, the entire _pinfo struct isn't mapped in, just the first 
page.  Of course, I'm a newbie in this sphere, so maybe I've missed 
something and there's sometimes a reason for this?  (The first part of 
the struct looks normal.) Otherwise, that would be another odd flaw.

Anyway, I can see that the strace process's shared _pinfo object is 
never fully populated:

_pinfo 0x30000 {
   pid 2800,
   process_state 0x00000001,
   ppid 0,
   exitcode 0
   cygstarted 0,
   dwProcessId 0x00000AF0,
   progname "D:\cygwin64\bin\strace.exe",
   uid 0,
   gid 0,
   pgid 0,
   sid 0,
   ctty 0,
   has_pgid_children 0
   start_time 1492881370,
   nice 0,
   stopsig 0,
   sendsig 0x0,
   exec_sendsig 0x0,
   exec_dwProcessId 0
}

So I would venture to say that is a problem.  Also, pinfo::init() should 
probably issure some error message if it waits 2-ish seconds and the 
struct still isn't correctly populated.

Is there a way to debug the children of strace?  It would make it a lot 
easier.  That's part of why I wrote the _pinfo::debug(), but also when I 
debug strace with gdb, the _pinfo struct IS properly populated.  The 
best problems are the ones that disappear when you try to debug them.

Thanks,
Daniel



--
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-22 17:21 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
2017-04-23 12:58               ` Daniel Santos [this message]
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=a4afe377-3b4f-8373-8116-e812a8d82fbe@pobox.com \
    --to=daniel.santos@pobox.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).