On Tue, 2008-07-01 at 07:34 -0400, Alexander Kabaev wrote: > On Tue, 01 Jul 2008 14:29:32 +0400 > Vladimir Grebenschikov <[EMAIL PROTECTED]> wrote: > > > On Tue, 2008-07-01 at 10:49 +0200, Gary Jennejohn wrote: > > > On Mon, 30 Jun 2008 22:28:44 +0400 > > > Vladimir Grebenschikov <[EMAIL PROTECTED]> 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
signature.asc
Description: This is a digitally signed message part
