In the last episode (Jun 28), tcobb@stripped said:
> > > We've recently been seeing this on other FreeBSD 3.2 systems,
> > > also. After tracking it down for a while, it is definitely a
> > > problem in the FreeBSD 3.2 libc_r.so, and namely appears to be
> > > caused by some changes in thread priority handling in that
> > > library between 3.1 and 3.2.
> >
> > So this is FreeBSD bug? Have you notified them about it?
>
> Yes, it appears to be a FreeBSD bug. We just discovered it last
> Friday, so I have not yet notified them of it. It is rather
> difficult to reproduce except under quite heavy load.
There was a mega-update to libc_r in the 4.0-current tree on the 20th;
if you can, see if you can build a 4.0 version of libc_r and see
whether that helps mysql or not. I'm sure the patches will filter back
to the 3.0 tree eventually, but until then...
Here's a couple of the changes related to thread scheduling and
mutexes:
o Temporarily set the state of a thread to PS_SUSPENDED when it
is first created and placed in the list of threads so that it
will not be accidentally scheduled before becoming a member
of one of the scheduling queues.
o Close a race condition in uthread_close. (Tor Egge)
o Protect the scheduling queues while modifying them in
pthread_cond_signal and _thread_fd_unlock. (Tor Egge)
o Ensure that when a thread gets a mutex, the mutex is on that
threads list of owned mutexes. (Tor Egge)
o Set the kernel-in-scheduler flag in _thread_kern_sched_state
and _thread_kern_sched_state_unlock to prevent a scheduling
signal from calling the scheduler again. (Tor Egge)
-Dan Nelson
dnelson@stripped
