From: Mike Coleman <mkc@mathdogs.com>
To: Pavel Kankovsky <peak@argo.troja.mff.cuni.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PTRACE_ATTACH breaks wait4()
Date: 08 Jun 2001 01:19:31 -0500 [thread overview]
Message-ID: <87u21ro5n0.fsf@mathdogs.com> (raw)
In-Reply-To: <20010607223921.D94.0@argo.troja.mff.cuni.cz>
In-Reply-To: <20010607223921.D94.0@argo.troja.mff.cuni.cz>
Pavel Kankovsky <peak@argo.troja.mff.cuni.cz> writes:
> Let A be a process and B its child. When another process, let's call
> it C, does ptrace(PTRACE_ATTACH) on B, wait4(pid of B, ...) will always
> return ECHILD when invoked from A after B has been attached to C because
> wait4() does not take children traced by other processes into account.
> The problem was observed on 2.2.19. I suppose it exists in 2.4 as well.
I bet it does, too. Personally I think ptrace needs to be replaced (see my
semi-rant from December below).
Does anyone see any reason why something along the lines of a Solaris-like
proc interface wouldn't be better? If I write up a minimal spec, would people
read it and poke holes in it? (Or maybe someone else is itching to do this?)
--Mike
>From December:
My limited mental abilities notwithstanding, I think this is one more
reason to ditch ptrace for a better method of process tracing/control.
It's served up to this point, but ptrace has a fundamental flaw, which is
that it tries to do a lot of interprocess signalling and interlocking in an
in-band way, doing process reparenting to try to take advantage of existing
code. In the end this seems to be resulting in an inscrutable, flaky mess.
What would a better process tracing facility be like? One key feature is
utter transparency. That is, it should be impossible for traced processes
or other processes that interact with them to be aware of whether or not
tracing is going on. This means that there should be no difference between
the way a process behaves under tracing versus how it would behave if it
weren't being traced, which is a key to faithful tracing/debugging and
avoiding the Heisenbug effect. (There does need to be some interface via
which information about tracing itself can be observed, but it should be
hidden from the target processes.)
It would also be nice to have something accessible via devices in the proc
filesystem. Maybe something like Solaris' "proc" debugging interface would
be a starting point:
http://docs.sun.com:80/ab2/coll.40.6/REFMAN4/@Ab2PageView/42351?Ab2Lang=C&Ab2Enc=iso-8859-1
--
Mike Coleman, mkc@mathdogs.com
http://www.mathdogs.com -- problem solving, expert software development
next prev parent reply other threads:[~2001-06-08 6:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-07 20:39 PTRACE_ATTACH breaks wait4() Pavel Kankovsky
2001-06-08 6:19 ` Mike Coleman [this message]
2001-06-08 8:47 ` David Howells
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=87u21ro5n0.fsf@mathdogs.com \
--to=mkc@mathdogs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peak@argo.troja.mff.cuni.cz \
/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