On Sep 22, 2008, at 3:39 AM, Peter Kjellerstedt wrote:
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chase Douglas Sent: den 19 september 2008 22:21 To: Chase N Douglas Cc: [email protected] Subject: Re: pthreads stress test hangs on read() returning EINTROn 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.Please take a look at http://uclibc.org/lists/uclibc/2008-March/019187.html which reported this problem half a year ago...
Thanks for pointing that out. However, like the submitter notes, it's not a full solution as it only encompasses the malloc-standard mutex. I need to be sure that a hang is not possible from any mutex so my thought is to take the mutex initialization macros and turn them into functions that will register the internal mutexes so that when fork() is called we can make sure to grab each mutex before we proceed.
Thanks, Chase
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
