From: Dmitry V. L. <ld...@al...> - 2011-08-17 13:56:08
|
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 |