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.
This is utrace bug, and is resolved for fc5 by dropping the utrace patch. Reporter should verify when the next fc5 update kernel is built that the problem is gone.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.