> -----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 EINTR > > 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 > [EMAIL PROTECTED] > (614) 456-0455
Please take a look at http://uclibc.org/lists/uclibc/2008-March/019187.html which reported this problem half a year ago... //Peter _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
