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