Bug 72881 - after forking a process and attempting to execve, the only two threads that are left are the forking thread (waitpid) and the forked thread (waiting for theads to be killed).
Summary: after forking a process and attempting to execve, the only two threads that a...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 7.2
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-08-28 17:43 UTC by george.miller
Modified: 2016-11-24 15:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-04 20:22: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 george.miller 2002-08-28 17:43:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (Windows NT 5.0; U)

Description of problem:
i have a threaded (5 threads) process that attempts to do the following:

    1) fork and execve a process.
    2) the forking process( thread) does a waitpid on the pid produced by the fork.
   3) the child process attempts to execve a binary, with a small number of parameters.

what is left after this is done is only two processes (threads). the first process is the original thread that did the fork and is now waiting on the 
waitpid. the second process is the forked process and is blocked down in the execve waiting to be restarted after some threads have been killed 
(pthread_kill_other_threads and pthread_wait_for_restart_signal) . i have stepped and stopped this process to know that the fork works ok, but as soon as the child 
process attempts to execve, all the threads except for the above 2 have disappeared. i can attach backtraces of each of these threads/processes if necessary.  as 
an aside, it definitely is very difficult trying to talk about threads and processes in linux since there is a very fine dividing line (actually this area is the only real thing 
that i do not like about linux especially since there is a lot to be desired in this area). we have other process that do this and works. the only difference that i can see 
is that in this case the fork is not done from the main thread. the same source when compiled and run on solaris 8 works fine.

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

How reproducible:

Steps to Reproduce:
1. without this binary, which is company private, i could not tell you how to reproduce it. i was hoping that the symptoms would ring a bell for someone. 

Additional info:

Comment 1 george.miller 2002-08-29 13:01:52 UTC
i am using kernel 2.4.9-31. i have tried different variations of trying to get this to work. all of these variants work on solaris, but none work on linux. this process is a 
server that accepts connections from clients and attempts to fork a process to handle the client's requests. i have a version that actually just uses threads to handle 
the client requests. the problem is that some vendor software that we use is not the most stable and occasionallly cores, thus bringing down the entire process and 
all connected clients. i am attempting to try this approach so that each client is independent of the other.

Comment 2 Krush Chavan 2002-12-16 17:51:14 UTC
I am encountering the same problem and I am adding a source program that 
simulates the problem and the sample output.

Please compile this sample program and you will notice the problem...
If you comment out the lines that create the pthread the execvp will work

***********Program Start**********************************************
#include <iostream.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>

void* monitorProcess(void *objProcessMgr)
   int icount;
   for (int icount=0;icount<20;icount++)
       cout << "Printing in another thread in 4 secs \n" << endl;
   return 0;

// Main

int main(void)
         pid_t pid;
	pthread_t m_MonitorThreadId;
	void * retval;

         if ((pid = fork()) < 0)
                 cerr << "Error creating fork" << endl;
         else if (pid == 0)
                 // This is the child process
	  char* argv[3] ={"Hello","World",NULL} ;
	  cout << "The PID of the child process is " << getpid() << endl;
	  execvp ("/home/krush/code/test/Printargs",argv);
	  cout << "Unknown command" << endl;
                 // This is the parent process
                 cout << "The PID of the parent process is " << getpid() << 
	// Line 2

****************Program Ends********************************************
Program Output
root> ./forkThread
The PID of the child process is 12238
The PID of the parent process is 12238

Ps Output

000 S root     12235  1322  0  69   0    -  3061 rt_sig 22:37 pts/1
00:00:00 ./forkThread
044 Z root     12236 12235  0  69   0    -     0 do_exi 22:37 pts/1    
[forkThread <defunct>]
040 S root     12238 12235  0  69   0    -  3061 rt_sig 22:37 pts/1
00:00:00 ./forkThread
000 S root     12555 12132  0  72   0    -   433 pipe_w 23:04 pts/2    
grep fork

Comment 3 Ben LaHaise 2002-12-16 17:55:02 UTC
The behaviour of fork() with POSIX threads is undefined.  Do not depend on this
behaviour in your programs.

Comment 4 Ben LaHaise 2002-12-16 18:02:54 UTC
Actually, glibc's info pages document the behaviour of only copying the thread
that is currently executing.  info libc and look for Threads and Fork.

Comment 5 Krush Chavan 2002-12-16 18:31:14 UTC

Thanks for the info, but if you notice that in the sample program that I have 
attached I am creating the fork in the main thread and not in the other thread.

Is this a problem in this version of the kernel or is it present in all 
versions. Is there an alternative approach that can solve this problem....


Comment 6 Ulrich Drepper 2003-04-22 06:52:33 UTC
Try using RHL9 with NPTL (the default thread library).

Comment 7 Bill Nottingham 2006-08-04 20:22:03 UTC
Red Hat Linux and Red Hat Powertools are currently no longer supported by Red
Hat, Inc. In an effort to clean up bugzilla, we are closing all bugs in MODIFIED
state for these products.

However, we do want to make sure that nothing important slips through the
cracks. If, in fact, these issues are not resolved in a current Fedora Core
Release (such as Fedora Core 5), please open a new issues stating so. Thanks.

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