pthreads stress test hangs on read() returning EINTR

[Peter Kjellerstedt]

> -----Original Message-----
> From: uclibc-bounces at uclibc.org [mailto:uclibc-bounces at uclibc.org] On
> Behalf Of Chase Douglas
> Sent: den 19 september 2008 22:21
> To: Chase N Douglas
> Cc: uclibc at uclibc.org
> 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
> cndougla at us.ibm.com
> (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