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: Always 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. 2. 3. Additional info:
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.
Hi 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 successfully ***********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; sleep(4); } return 0; } // // Main // int main(void) { pid_t pid; pthread_t m_MonitorThreadId; pthread_create(&m_MonitorThreadId,NULL,monitorProcess,NULL); 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; exit(0); } else { // This is the parent process cout << "The PID of the parent process is " << getpid() << endl; } // Line 2 pthread_join(m_MonitorThreadId,&retval); return(0); } ****************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 00:00:00 [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 00:00:00 grep fork
The behaviour of fork() with POSIX threads is undefined. Do not depend on this behaviour in your programs.
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.
Ben 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.... Krush
Try using RHL9 with NPTL (the default thread library).
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.