All,
[please keep me on CC:, not on this list]
I recently started to experience more frequent occurrences of both firefox
(3.x and 2.0.0.16) and thunderbird consuming 100% of one Sparc CPU on my
U45 with not even a refresh of the window I was trying to look at happening.
A typical truss on such a process would look something like:
/11: lwp_park(0xF6DFBB90, 0) Err#62 ETIME
/266: lwp_park(0xF6BFBB90, 0) Err#62 ETIME
/264: lwp_park(0xF8E7BB90, 0) Err#62 ETIME
/31: lwp_park(0xF5BFBB90, 0) Err#62 ETIME
/270: lwp_park(0xF5FFBB90, 0) Err#62 ETIME
/272: lwp_park(0xF8F7BB90, 0) Err#62 ETIME
/9: lwp_park(0x00000000, 0) (sleeping...)
/276: lwp_park(0x00000000, 0) (sleeping...)
/277: lwp_park(0x00000000, 0) (sleeping...)
/1: lwp_park(0x00000000, 0) (sleeping...)
/14: lwp_park(0x00000000, 0) (sleeping...)
/8: lwp_park(0x00000000, 0) (sleeping...)
/3: lwp_park(0x00000000, 0) (sleeping...)
/2: lwp_park(0x00000000, 0) (sleeping...)
and so on ad nauseam.
As far as I'm aware of, this only happens when I return focus to that
window (though not every time, luckily) after some period of inactivity,
the length of which seem to be directly propoertional to the likelihood of
this happening.
Since I upgraded to b100a, this seems to have gotten much worse.
I ran the following dtrace script on one of these processes when it got
into said state:
profile:::profile-7ms
/pid == 83/
{
@c[ustack(10)] = count()
}
tick-10s
{
exit(0)
}
if you're on SWAN, the resulting output is in
/net/erdinger.sfbay/export/ff.trace (100k), in case someone wants to have a
look. I can also send it in private, if someone wants it.
TIA for suggestions, pointers ...
Michael
--
Michael Schuster http://blogs.sun.com/recursion
Recursion, n.: see 'Recursion'
