pthreads stress test hangs on read() returning EINTR

Chase Douglas cndougla at us.ibm.com
Fri Sep 19 20:21:23 UTC 2008


On Sep 19, 2008, at 4:05 PM, Chase N Douglas wrote:
> 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?

After a second glance I see that the only locks this applies to are  
pthread_mutex_t locks and other types derived from pthread_mutex_t  
locks. Inside uClibc itself this seems to be only malloc locks and  
regex locks. I will be trying to put together a patch that will take  
care of both of these types of locks when forking.

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/07a7314c/attachment-0002.bin 


More information about the uClibc mailing list