Bug 142899 - waitpid stops seeing child process once gdb attaches to it
Summary: waitpid stops seeing child process once gdb attaches to it
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 2.1
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jim Paradis
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-12-14 22:38 UTC by Mikhail Kruk
Modified: 2013-08-06 01:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-05 22:53:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Mikhail Kruk 2004-12-14 22:38:50 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3)

Description of problem:
I have a simple program (I'll try to attach it) which forks a child.
The child sleeps and the parent calls waitpid(childpid, &status,
WNOHANG) in a loop. While child sleeps waitpid returns 0 like it
should.  Then I go and attach to the child with a debugger. When I do
that the parent's behavior change: waitpid starts returnign -1 and
errno is set to 10 (no child processes). Once I restart child in the
debugger waitpid goes backto normal behavior. 
This is bad because there is no way to tell with waitpid whether child
process is being debugger or is gone.
RH ES 3 does not have this problem.

I also tried changing WNOHANG to WNOHANG | WUNTRACED 
and looking at WIFSTOPPED() but that didn't change anything and
WIFSTOPPED is always 0.

Version-Release number of selected component (if applicable):
glibc-2.2.4-32.18, kernel-2.4.9-e.57

How reproducible:

Steps to Reproduce:
1. Run the sample program
2. Attach to the child process with gdb
3. Profit!

Actual Results:  waited: pid 0 status: 134514001 errno: 0 0
waited: pid -1 status: 134514001 errno: 10 0
waited: pid 1736 status: 0 errno: 0 0

Expected Results:  waited: pid 0 status: 134514001 errno: 0 0
waited: pid 1736 status: 0 errno: 0 0

Additional info:

#include <stdlib.h>  
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/wait.h>
#include <fcntl.h>
#include <errno.h>

	pid_t pid, wpid;
	int status;
	pid = fork();
	if( pid != 0 )
		printf("parent of child: %d\n", pid);
			errno = 0;
			wpid = waitpid(pid, &status, WNOHANG | WUNTRACED);
			printf("waited: pid: %d status: %d errno: %d %d\n", wpid, status,
errno, WIFSTOPPED(status));
		int i;
		for (i = 0; i < 15; i++)
		printf("child done\n");

Comment 1 Jakub Jelinek 2004-12-15 09:22:15 UTC
glibc's waitpid just results in a syscall with no argument changes whatsoever.

Comment 3 Jakub Jelinek 2004-12-20 14:47:19 UTC
What I meant that waitpid issues are not a bug in glibc, but in the kernel
(if it is a bug at all).  Because all glibc does is issue a syscall if the
user calls waitpid.

Comment 5 Jim Paradis 2005-12-05 22:53:03 UTC
This issue is outside the scope of the current support status for RHEL2.1.  No
fix is planned.

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