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
[EMAIL PROTECTED]
(614) 456-0455
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
