Bug 216149

This bug occures on the fc5.18 (e.x., 2.6.18-1.2239.fc5) series of kernels.  It
does not occure on the fc5.17 series.

+++ This bug was initially created as a clone of Bug #216020 +++

Description of problem:

A detached daemon process, when it exits, returns WIFSIGNALED instead of
WIFEXITED (actually it also generates a WIFEXITED).

Version-Release number of selected component (if applicable):

How reproducible:

100%

Steps to Reproduce:

Run attached test case.
  
Actual results:

24081 installing signal handler and mask
24081 forking
24083 signalling 24081 with User defined signal 1
24083 waiting for signals
24081 calling waitpid 24082 for << child for daemon exits >> returns 0x0
WIFEXITED 0 -- ok
24081 waiting for signals
24081 received User defined signal 1
24081 calling ptrace 16 (ATTACH) 24083 0
24081 calling waitpid 24083 for << daemon attached >> returns 0x137f WIFSTOPPED
19 -- ok
24081 calling ptrace 21 (SETOPTIONS) 24083 80
24081 calling ptrace 7 (CONT) 24083 10
24081 calling waitpid 24083 for << daemon stops at exec >>24083 received User
defined signal 1
 returns 0x4057f WIFSTOPPED 5 -- ok
24081 calling ptrace 7 (CONT) 24083 0
24081 calling waitpid 24083 for << daemon stops at exit(47) >>24083 argc 3 0 47
exiting 24083 with 47
 returns 0x6057f WIFSTOPPED 5 -- ok
24081 calling ptrace 7 (CONT) 24083 0
24081 calling waitpid 24083 for << daemon does exit(47) >> returns 0x2f
WIFSIGNALED 47 -- WIFEXITED 47 expected
Aborted (core dumped)

Expected results:

30389 installing signal handler and mask
30389 forking
30391 signalling 30389 with User defined signal 1
30391 waiting for signals
30389 calling waitpid 30390 for << child for daemon exits >> returns 0x0
WIFEXITED 0 -- ok
30389 waiting for signals
30389 received User defined signal 1
30389 calling ptrace 16 (ATTACH) 30391 0
30389 calling waitpid 30391 for << daemon attached >> returns 0x137f WIFSTOPPED
19 -- ok30389 calling ptrace 21 (SETOPTIONS) 30391 80
30389 calling ptrace 7 (CONT) 30391 10
30389 calling waitpid 30391 for << daemon stops at exec >>30391 received User
defined signal 1
 returns 0x4057f WIFSTOPPED 5 -- ok
30389 calling ptrace 7 (CONT) 30391 0
30389 calling waitpid 30391 for << daemon stops at exit(47) >>30391 argc 3 0 47
exiting 30391 with 47
 returns 0x6057f WIFSTOPPED 5 -- ok
30389 calling ptrace 7 (CONT) 30391 0
30389 calling waitpid 30391 for << daemon does exit(47) >> returns 0x2f00
WIFEXITED 47 -- ok
30389 calling waitpid 30391 for << no children >> fails (No child processes) -- ok

Additional info:

Will try to further reduce test, see frysk's testsuite for current version.

-- Additional comment from cagney on 2006-11-16 14:48 EST --
Created an attachment (id=141405)
test case


-- Additional comment from cagney on 2006-11-16 14:55 EST --
Frysk's bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=3525
Frysk's testcase:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/frysk-imports/tests/frysk3525/exit47.c?cvsroot=frysk

-- Additional comment from cagney on 2006-11-16 15:13 EST --
The exec isn't needed, nor is SETOPTIONS, both removed from frysk's test case.


-- Additional comment from cagney on 2006-11-16 15:47 EST --
$ ssh towns uname -a
Linux towns.toronto.redhat.com 2.6.18-1.2849.fc6 #1 SMP Fri Nov 10 12:36:14 EST
2006 i686 i686 i386 GNU/Linux


-- Additional comment from roland on 2006-11-17 03:30 EST --
The test case is slightly racy and on a well-behaving kernel it will sometimes
barf when it sees a WIFSTOPPED/WTERMSIG=SIGUSR1 result, which is a valid
possibility when the parent's PTRACE_CONT with SIGUSR1 comes before the child
has unblocked SIGUSR1 in the sigsuspend syscall; this will happen on a fast
machine or a preemption kernel.  The ptrace behavior is to requeue the
PTRACE_CONT-specified signal when it's blocked, so that it comes back through
ptrace when it's unblocked--whereas when the signal is already unblocked because
the child has gotten far enough into its sigsuspend call, then PTRACE_CONT's
injection of the signal goes directly to running the handler as the test case
expects.  

The only mystery about the utrace bug is how we went so long without noticing
it.  The waitpid result for the exit of a PTRACE_ATTACH'd task (not your own
child) is just always wrong.  It's a simple fix.

-- Additional comment from cagney on 2006-11-17 09:34 EST --
(In reply to comment #5)
> The test case is slightly racy and on a well-behaving kernel it will sometimes
> barf when it sees a WIFSTOPPED/WTERMSIG=SIGUSR1 result, which is a valid
> possibility when the parent's PTRACE_CONT with SIGUSR1 comes before the child
> has unblocked SIGUSR1 in the sigsuspend syscall

I wondered about that, I'll slow down the test, tks.