Date: Mon, 24 Oct 2005 10:26:39 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Sven Berkvens-Matthijsse <sven@ilse.net> Cc: Marc Olzheim <marcolz@stack.nl>, Marc Olzheim <marcolz@ilse.net>, David Xu <davidxu@freebsd.org>, freebsd-threads@freebsd.org Subject: Re: threads/76690: fork hang in child for (-lc_r & -lthr) Message-ID: <Pine.GSO.4.43.0510241018350.16970-100000@sea.ntplx.net> In-Reply-To: <20051024140023.GM22568@ilse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Oct 2005, Sven Berkvens-Matthijsse wrote: > > I'm not interested in maintaining libc_r, but I looked at the fix. > > It exports symbols into the application namespace (those without > > leading underscores). > > It does (which I can fix if you'd like). The reason is that I only > changed the names of those mutexes and spinlocks that were called > "thread_lock". I'm lazy, I know :-) > > > It also looks to me like an application bug since you can only use > > async signal safe functions in the child after a fork() from a > > threaded application and before an exec() of some sort. > > That's correct, but the libc_r library calls free() itself to clean up > after all threads other than the current one (which according to the > specs don't exist in a forked program). So it's a bug in the library, > I guess, because it calls non-async-signal-safe functions itself. > See /usr/src/lib/libc_r/uthread/uthread_fork.c, in which the freeing > happens. WRT to malloc() and free() within libc_r, it is always single threaded from the library's perspective because no other threads can be active at the time of the fork (libc_r is all userspace threads). Probably all that needs to be done is take the malloc lock before forking and release it afterwards (like libpthread). It may even be enough just to set __isthreaded to 0 in the child after the fork() before calling any malloc()'s and free()'s so they don't try to use the lock. If __isthreaded is 0 in the child, I don't think any part of libc will attempt to use locking. If the child tries to create any threads, then bad things may happen, but that's the application's fault. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0510241018350.16970-100000>