>
> >Now you get to the almost indescribable problems we've had running a
> >threaded MPM, or even a non-threaded MPM which links with libc_r and
> >adds a thread lock here and there within APR, on various levels of
> >reeBSD.
>
I would describe it as the Apache parent process and at least two
children looping. One of these is in _thread_sigframe_restore() from
/usr/lib/libc_r.so.4 , as posted earlier.
> You see this with the prefork mpm too?
Yep. Haven't been brave enough to try a threaded mpm until this simpler
case is resolved.
> Is there a reproducible test case or is it seemingly random?
I can recreate it on daedalus (apache.org's host) without trying very
hard, by replaying a bit of the log. Going live also does it in spades.
Unfortunately we don't yet have an offline system with BSD 4.2-STABLE
and apache.org's www content. We haven't been able to narrow the
problem down further on daedalus - we have to kill the loopers quickly
since it's a production machine.
>
> Could it be related to this output from configure?
>
Yes, but I'm afraid you have it backwards. The output from configure is
due to this bug.
> --
> Applying APR hints file rules for i386-unknown-freebsd4.1
> Adding "-lcrypt" to LIBS
> Setting enable_threads to "no"
> Adding "-D_REENTRANT -D_THREAD_SAFE" to THREAD_CPPFLAGS
> --
>
> Why is enable_threads "no"?
>
Because if you enable threads in Apache on BSD, the server loops.
Disabling threads circumvents the loop for now. I'm guessing
--enable-threads causes us to link with the threaded libraries.
Charles, if you are familiar with BSD's thread support and willing to
help with debugging our loop, I think Brian would be receptive to giving
us another test shot with threads enabled. I can run the test script.
We just have to assume it will loop, and be ready to quickly gather doc
and kill it.
Greg
