pthreads stress test hangs on read() returning EINTR

Chase Douglas cndougla at us.ibm.com
Fri Sep 19 20:05:10 UTC 2008


I believe I have found the issue. Suppose there are threads A and B.  
Thread A is running and is in the critical section of malloc() where  
locks are held to manage the heap and such. A context switch then  
occurs before thread A can relinquish the malloc locks. Thread B now  
attempts to fork. After forking, the parent process (still thread B)  
continues as normal, but the new child process immediately attempts to  
free the manager thread resources as it's no longer needed. At this  
point, the child process attempts to grab the malloc locks to free the  
memory, but it sees that someone is holding the lock (what used to be  
thread A). We now have a deadlock since even if thread A relinquishes  
the lock, it's in a separate process now with a separate virtual  
memory space. The lock state in the child process will never be  
relinquished. For this reason, such locks should be held before  
forking, the parent process after the fork should relinquish them, and  
the child process after the fork should reinitialize them.

However, there are many locks in uClibc and not a single one is  
managed in this way before and after forking. Shouldn't every single  
lock be dealt with before and after forking, or am I missing something  
here?

Thanks
--

Chase Douglas
IBM Linux Technology Center
cndougla at us.ibm.com
(614) 456-0455

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3892 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20080919/91905658/attachment-0002.bin 


More information about the uClibc mailing list