Bug 216149 - waitpid on exiting daemon returns WIFSIGNALED instead of WIFEXITED
waitpid on exiting daemon returns WIFSIGNALED instead of WIFEXITED
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
bzcl34nup
:
Depends On: 216020
Blocks: 173278
  Show dependency treegraph
 
Reported: 2006-11-17 09:44 EST by Andrew Cagney
Modified: 2015-01-04 17:29 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 12:51:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Cagney 2006-11-17 09:44:20 EST
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@redhat.com on 2006-11-16 14:48 EST --
Created an attachment (id=141405)
test case


-- Additional comment from cagney@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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.
Comment 1 Roland McGrath 2006-11-17 15:30:19 EST
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.
Comment 2 Bug Zapper 2008-04-04 00:45:09 EDT
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
Comment 3 Bug Zapper 2008-05-06 12:51:01 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.