[PATCH] RFC: do not detach when we think tracee is going to die

[Dmitry V. Levin]

On Wed, Aug 17, 2011 at 03:37:40PM +0200, Denys Vlasenko wrote:
> On Wed, 2011-08-17 at 14:45 +0400, Dmitry V. Levin wrote:
> > On Mon, Aug 15, 2011 at 12:01:56PM +0200, Denys Vlasenko wrote:
> > > On Tue, 2011-08-02 at 01:45 +0400, Dmitry V. Levin wrote:
> > > > On Sat, Jun 25, 2011 at 11:34:23AM +0200, Denys Vlasenko wrote:
> > [...]
> > > > > I need to look in the past to figure out why we even do it.
> > > > > First guess is that it's a workaround for old kernel bugs.
> > > > 
> > > > How old those buggy kernels might be?
> > > 
> > > The internal_exit function, whose reason for existence is to 
> > > support "detach on exit" behavior, is from 1995.
> > > 
> > > I tried to test whether this is still needed on kernel 2.4.20,
> > > but this kernel oopses (somewhere in ptrace_check_attach).
> > 
> > I tried to test current strace with linux-2.4.32-ow1 from
> > ftp://ftp.openwall.com/pub/Owl/2.0-release/iso/Owl-2.0-release-i386.iso.gz
> > where PTRACE_SETOPTIONS are certainly not supported, and found out that
> > test_ptrace_setoptions_followfork() fails to wait for all child processes
> > it generates, resulting to an unexpected wait failure later in
> > test_ptrace_setoptions_for_all().
> > 
> > I've just pushed a fix to
> > http://strace.git.sourceforge.net/git/gitweb.cgi?p=strace/strace;a=commitdiff;h=ldv/PTRACE_SETOPTIONS-tests
> > please have a look.
> 
> Took a look. It's not readily apparent where the fix is,

Old code in test_ptrace_setoptions_followfork() was SIGKILLing the child
process in case of PTRACE_SETOPTIONS failure without waiting for this
process.  As result, test_ptrace_setoptions_for_all() was confused by
unexpected WIFSIGNALED wait status.  This change reorganizes the code
to avoid unnecessary SIGKILLings.

> but I trust that you tested it :)

Certainly.

> > With the fix, at least simple strace -f test works on linux-2.4.32.
> > There are no kernel oopses there, but ./strace -f ./test/childthread
> > outputs something different from expected.
> >
> > > Do you think it would be better if we recommend users of
> > > 2.4 kernels to simply stick with older strace versions?
> > 
> > Do we have an alternative choice now?
> 
> Alternative choice is to test/fix our current code at least on the
> latest 2.4.x, but I don't have suitable test environment with 2.4
> kernels. A qemu image would be ideal...

OK, I'll try to prepare one.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20110817/4b74f397/attachment.bin>