X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=ig9cV+qexJRgp58O
	Znj9nIJZTgL2dadQ8Mh9pbZf8uDujhM8Ge7KSANh++1zRzhdPjiEM/2qN0yd1ta2
	Y2LOTbbrNWVtfi/TV3/rxVo89mLYcekPX1cmSbQOzcPFCFy2MwMkOKCh/H32B3z/
	q/BVRtk6Cu2Hg3COrCG+nEzwJCQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=iGfiOaH9TA+NHZlj5cBnCO
	Ki7s0=; b=KMwEv2f718M+N4W6J6e4UhlcGeWKb0KtaEOeFTX76tDBRMGlMGt9Uh
	MlyhSHK8raYfiBlAIR9vKIfrcZhtK4GyFzSBD2YY7DQL/9PhQ+OEDIdYU9TgiR0W
	d828I2dgbRFe2X05Mfp+hTy001Y90vFwhpPfJx/XDxaSV9iwlEf48=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=venture, cygwin64, awaiting, wish
X-HELO: sasl.smtp.pobox.com
Subject: Re: long I/O delays when strace is running
To: cygwin AT cygwin DOT com
References: <be8713ec-5b68-e0e9-c5a5-d48fce491a2d AT pobox DOT com> <91DCAC3CB99C724EB365BB64677FBE7B16EBBD AT MX204CL04 DOT corp DOT emc DOT com> <46e39bce-9782-5c74-c196-35ee97ebbc64 AT pobox DOT com> <ace81c86-80d5-bef9-6b93-7d36dde5a4e8 AT pobox DOT com> <bff9c5ea-85d9-bf4e-2f25-271c1490565f AT pobox DOT com> <58F9D314 DOT 2000100 AT maxrnd DOT com> <7d56e728-32a3-9179-b002-e83880e297d0 AT pobox DOT com> <58FA83DB DOT 3000209 AT maxrnd DOT com>
From: Daniel Santos <daniel DOT santos AT pobox DOT com>
Message-ID: <a4afe377-3b4f-8373-8116-e812a8d82fbe@pobox.com>
Date: Sat, 22 Apr 2017 12:25:52 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <58FA83DB.3000209@maxrnd.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 154BD0E8-2780-11E7-A38E-C260AE2156B6-06139138!pb-smtp2.pobox.com
X-IsSubscribed: yes


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