Re: [fwd] cvs commit: src/lib/libthr/thread thr_mutex.c thr_umtx.c thr_umtx.h src/sys/kern kern_umtx.c src/sys/sys umtx.h

On Tue, 2008-07-01 at 07:34 -0400, Alexander Kabaev wrote:
> On Tue, 01 Jul 2008 14:29:32 +0400
> Vladimir Grebenschikov <vova_at_fbsd.ru> wrote:
> 
> > On Tue, 2008-07-01 at 10:49 +0200, Gary Jennejohn wrote:
> > > On Mon, 30 Jun 2008 22:28:44 +0400
> > > Vladimir Grebenschikov <vova_at_fbsd.ru> wrote:
> > > 
> > > > On Tue, 2008-06-24 at 07:32 +0000, David Xu wrote:
> > > > 
> > > > This commit makes threaded application almost unusable on
> > > > 8-CURRENT.
> > > > 
> > > > Applications eat 100% CPU all the time and works _very_ slowly.
> > > > (top shows several threads for every constantly applications
> > > > eating CPU)
> > > > 
> > > > Following applications are affected for me: firefox, evolution,
> > > > eclipse (probably more).
> > > > 
> > > > Reverting user-land part of commit fixes problem, reverting kernel
> > > > changes nothing regarding the problem.
> > 
> > ...
> > 
> > > Did you recompile these misbehaving applications?
> > > 
> > > I ask because I installed a fresh world yesterday, without
> > > recompiling any ports, and I'm _not_ seeing any misbehavior with
> > > firefox.
> > 
> > Do you have SMP system ? 
> > 
> Works fine for me on amd64 SMP and i386 UP systems, world build on June
> 29th on both.
> 
> Could you ktrace firefox-bin while it spins? Just in case...
> 

Firefox depends upon a lot of external things, including glib, nss, and
nspr (among others, probably) which would propagate thread-lib bugs even
after the main app has been recompiled. I suggest running ldd
on /usr/local/lib/firefox/firefox-bin (and other shared objects in that
dir) to find out what all you might need to rebuild. At the very least,
I'd expect a rebuild of nspr and nss to be mandatory. I *think* firefox
uses nspr's thread implementation, and not the one from gthread (glib).

-- 
Coleman Kane