Date: Mon, 24 Oct 2005 16:00:23 +0200 From: Sven Berkvens-Matthijsse <sven@ilse.net> To: Daniel Eischen <deischen@freebsd.org> 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: <20051024140023.GM22568@ilse.net> In-Reply-To: <Pine.GSO.4.43.0510240944210.16730-100000@sea.ntplx.net> References: <20051024121145.GB25866@stack.nl> <Pine.GSO.4.43.0510240944210.16730-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. > -- > DE -- Sven
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051024140023.GM22568>