Red Hat Bugzilla – Bug 74437
Calling fork() from a pthread randomly nukes some of the other threads
Last modified: 2016-11-24 09:59:01 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 Description of problem: The attached program creates ten threads that waste cycles for three secs, then finish. An eleventh thread waits half a sec and then does a fork()/exec(). Some of the times (one in ten?) I run this program, most of the threads get killed off before finishing. I have tried this on RHAS2.1 on both IA32 and IA64 and get similar results on both platforms. Version-Release number of selected component (if applicable): 2.2.4-26 (on IA32) and 2.2.4-27.2 on (IA64) How reproducible: Sometimes Steps to Reproduce: 1. Build the attached program (passing -lpthreads to gcc). 2. Run it. Actual Results: Some of the threads get killed off before finishing. Expected Results: All threads should report they have finished. Additional info:
Created attachment 77009 [details] Test program, build with gcc -lpthreads
Actually, I just discovered that the exec() doesn't have anything to do with this. If you do exit(0) the first thing you do in the child, you still get the same behaviour :-(. Tested on RHAS/ia32 and RHAS/ia64. This (obviously) makes it impossible to (reliably) do fork()/exec() from any threaded app.
For what it's worth, I am unable to reproduce the problematic behaviour inside GDB. As GDB and pthreads are rather entangled this is not entirely surprizing.
Regardless of fork() or not, all threads are terminated when the main thread terminates. Since the main thread was performing the same time-wasting operation as all the others, there was a race giving different behaviour depending on how the threads got scheduled. You learn something new every day :-).