Date: Sat, 18 Mar 2000 10:15:22 +0100 (CET) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= <mikko@rsasecurity.com> To: gnats-admin@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/17437: pthread_atfork() missing from libc_r Message-ID: <Pine.BSF.4.21.0003181011480.19450-100000@shiba.d.home.dynas.se> In-Reply-To: <200003171830.KAA86314@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
(Following up on myself, after further investigations):
Nope, the above patch is insufficient, it just serves to uncover
more bugs...
The problem is that libc_r does not do complete cleanup of the other
threads after the fork. All deleted threads must be quietly removed
from any queues they happen to be waiting in, or they may later be
subject to "revival" after they have been freed.
Scenario (typical use of pthread_atfork()):
- forking thread aquires a number of mutexes.
- another thread waits on one of the mutexes
- after forking, the mutexes are released,
which will make any waiting threads
runnable -- but they have been deallocated!
- Bad Things(tm) happen...
All mutexes where this may happen can be conveniently located via the
"mutexq" field of the running thread, so this particular scenario is
easily fixed.
There is no similar way to handle threads queued on, for example,
condition variables, as there is no way to find the head of the "qe"
and "pqe" queue entries. The "join_queue" should be emptied too.
Basically, right now libc_r does not work at all after a fork().
Regards,
/Mikko
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0003181011480.19450-100000>