cvs commit: src/lib/libkse/thread thr_kern.c
Daniel Eischen
deischen at freebsd.org
Thu Jan 17 18:56:35 PST 2008
On Thu, 17 Jan 2008, Julian Elischer wrote:
> Landon Fuller wrote:
>>
>> On Dec 2, 2007, at 09:31, Arno J. Klaassen wrote:
>>
>>> For info, the attached patch, which partially reverts mfc of rev 1.286
>>>
>>> of kern_fork.c, seems to work as well (without the above patch to be
>>> clear),
>>>
>>
>> I just upgraded our 8-core build server from pre-november 6-STABLE to
>> 6.3-RELEASE, and ran into this issue, causing our fork-heavy builder
>> processes to lock up regularly.
>>
>> Your suggested patch (reverting the 1.286 MFC to sys/kern/kern_fork.c)
>> allows our builds to run to completion; I'll try digging into this further.
>> Given how easy this is to reproduce, I'm hoping this is possible to fix
>> before 6.3 is officially released?
>
>
> This is a problem.. the reason it was changed was that the
> previous code results in heavily loaded threaded processes that
> fork, hanging in indefinite lockups IN THE KERNEL. Eventually
> the whole machine would become unuseable. In particular when
> there is NFS being used but in other situations too. SO I'm
> damned if I do and damned if I don't on this.
>
> We were able to prove to ourselves that if a program got into this
> state it was a definite programming error. As was stated in the
> discussion to this change:
> "The change is trying to protect the user from doing something that they
> shouldn't be doing anyhow."
> The previous kernel tried to stop all other threads from running
> and thus, stopping them from changing anything, while the
> kernel copies the memory into the child process. The fact is that
> the kernel can't really protect the process from doing this and
> the other threads in the parent can still leave things in a state
> that will screw up the child.
>
> I gather it is the PARENT that hangs here?
It must be the child that hangs.
> It's possible that the answer is that the library needs to
> be changed as well. Dan, what is the library doing here?
I suppose it is malloc() that is getting into an inconsistent
state in the child. Creating a thread causes malloc() usage,
so threads in the parent can cause the malloc lock to look
like it's been locked just as the process is forked from a
different thread.
You might want to check out any differences between libkse
in -current and libpthread in 6.x. I don't think there is
an issue with -current.
--
DE
More information about the freebsd-java
mailing list