Date: Tue, 25 Oct 2005 09:16:19 +0200 From: Sven Berkvens-Matthijsse <sven@ilse.net> To: Daniel Eischen <deischen@freebsd.org> Cc: Marc Olzheim <marcolz@stack.nl>, freebsd-threads@freebsd.org, Marc Olzheim <marcolz@ilse.net>, David Xu <davidxu@freebsd.org>, Sven Berkvens-Matthijsse <sven@ilse.net> Subject: Re: threads/76690: fork hang in child for (-lc_r & -lthr) Message-ID: <20051025071619.GS22568@ilse.net> In-Reply-To: <Pine.GSO.4.43.0510241239180.17636-100000@sea.ntplx.net> References: <20051024144529.GP22568@ilse.net> <Pine.GSO.4.43.0510241239180.17636-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > But then the free() in the child process may be using an unstable > > state of the malloc system (because if you don't acquire the lock > > before the fork(), malloc() may be busy in the middle of the > > fork()). > > I don't think that can happen because libc_r will not switch out a > thread that is in a critical region (and libc locks are critical > regions) until it leaves the region. What code leads you to that conclusion? All the malloc functions simply lock a spinlock, do their work, and then unlock the spinlock. If the code gets interrupted by a timer signal and the thread scheduler schedules a thread that calls fork(), the malloc system will be in an unstable state in the child process, and when the thread library calls free() itself, the spinlock will already be locked, causing free() to hang. If you decide to set __isthreaded to 0, free() will be manipulating data that was in the process of being manipulated by the parent process (and is now in a potentially unusable state). > -- > DE -- Sven
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051025071619.GS22568>