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