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
pgpUzOH5YspBJ.pgp
Description: PGP signature
------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
