On Wed, Oct 01, 2008 at 10:20:48PM +0900, Izumi Tsutsui wrote: > I wrote: > > > > > - An assertion caused by firefox3 on 4.0 environment I reporeted > > > > can't be reproducible 100%. (some race condition?) > > > > > > Yes. I believe the problem is in delivering two or more unblocked upcalls > > > at once. The second one comes out garbled. Last night, I looked at the > > > code, and I can't see a substantive difference between the two. I'll try > > > again tonight. I also have a test case program in mind. > > > > I'm now trying firefox-2.0.0.17 (Bon Echo) from 4.0/i386 packages. > > It sometimes freezes silently after ~30 minutes browsing, > > but I'm not sure it's revivesa specific. > > It looks some LWPs died: > --- > % ps axsw | grep firefox > 100 514 531 40492 6 3 73 0 113488 276 lwpwait DW ttyp1 5:30.66 > /usr/pkg/lib/firefox/firefox-bin Ok, this thread is waiting for the others to exit. > 100 514 531 40492 3 3 73 0 113488 276 - U ttyp1 5:30.66 > /usr/pkg/lib/firefox/firefox-bin > 100 514 531 40492 1 3 73 0 113488 276 - U ttyp1 5:30.66 > /usr/pkg/lib/firefox/firefox-bin And according to PS, 'U' means these are suspended. I'm confused. It looks like we're in sigexit(). Oh.... I bet the problem is the code expects LW_WEXIT for its rapid-exit tests. Core dumps don't set that now. I bet you had a thread that had blocked and, on its way out, it put itself back on the upcall-needed queue. Please try with rev 1.91.2.45 of kern_sa.c. I expanded the tests so everywhere we looked for LW_WEXIT, we now also look for PS_WCORE (and PS_WEXIT). > 100 4601 531 0 1 1 63 0 92 32 piperd S ttyp1 0:00.00 > grep firefox > % > --- > > And it can't be killed even by kill(1) -KILL now. Yeah, it's in the process of exiting... Take care, Bill
Attachment:
pgpc0_Ia6K7TK.pgp
Description: PGP signature