[OpenIndiana-discuss] Performance problem with Flash & Firefox 4.0 b10

[Bill Sommerfeld]

On 02/01/11 12:14, Hillel Lubman wrote:
> After upgrading to Frefox 4.0 b10 and Flash plugin 10.1 r102 on OpenIndiana
> oi_148, Flash started to consume close to 100% CPU when activated, as well
> as crashing quite often. Is it a known issue?

I've seen this with Firefox 4.0b10 and Firefox 4.0b11.

truss shows lots of yield() system calls (mpstat suggests over 300k per 
second).  pstack shows the following stack traces:

: 2 %; c++filt </tmp/ffloop
-----------------  lwp# 12 / thread# 12  --------------------
  fe920e67 yield    (d7591ac0, f3bf21a0, f0affde8, 0, e7eea168, 
fea6d3dc) + 7
  fea4ae3a PR_Sleep (0) + a2
  fcfe4693 unsigned mozilla::storage::AsyncExecuteStatements::Run() 
(d4794290, 1, f0affed8, 0) + 2e3
  fd5fcf33 unsigned nsThread::ProcessNextEvent(int,int*) (e7efc880, 1, 
f0afff3c, fd57a580) + 22f
  fd57a5b5 int NS_ProcessNextEvent_P(nsIThread*,int) (e7efc880, 1, 
f0afff6c, fd5fbdd4) + 45
  fd5fbe48 void nsThread::ThreadFunc(void*) (e7efc880) + 94
  fea49be1 _pt_root (e7eed6a0, fe9ae000, f0afffe8, fe91c03e) + c9
  fe91c093 _thrp_setup (f9a75a40) + 9b
  fe91c320 _lwp_start (f9a75a40, 0, 0, 0, 0, 0)

-----------------  lwp# 20 / thread# 20  --------------------
  fe920e67 yield    (c0af65c0, f3bf21a0, e69fede8, 0, e7cab688, 
fea6d3dc) + 7
  fea4ae3a PR_Sleep (0) + a2
  fcfe4693 unsigned mozilla::storage::AsyncExecuteStatements::Run() 
(de313f10, 1, e69feed8, 0) + 2e3
  fd5fcf33 unsigned nsThread::ProcessNextEvent(int,int*) (e7cd2280, 1, 
e69fef3c, fd57a580) + 22f
  fd57a5b5 int NS_ProcessNextEvent_P(nsIThread*,int) (e7cd2280, 1, 
e69fef6c, fd5fbdd4) + 45
  fd5fbe48 void nsThread::ThreadFunc(void*) (e7cd2280) + 94
  fea49be1 _pt_root (e7699080, fe9ae000, e69fefe8, fe91c03e) + c9
  fe91c093 _thrp_setup (f9a79a40) + 9b
  fe91c320 _lwp_start (f9a79a40, 0, 0, 0, 0, 0)

I downloaded the firefox source.  The code suggests that sqlite is 
returning SQLITE_BUSY errors to the AsyncExecuteStatements code, and 
it's busy-looping -- calling PR_Sleep(0).

I haven't looked at why sqlite would return SQLITE_BUSY yet, but this is 
at least consistent with url completion not working when the process 
gets into this stuck state.

as an experiment I've hot-patched my running binary to change it to a 
PR_Sleep(1) (don't have a build environment set up to build firefox..) 
so it shouldn't burn as much cpu.

							- Bill