On Thu, Sep 06, 2001 at 11:55:19AM -0700, John Baldwin wrote:
>
>
> Note that 3 of these are runnable (stat of 2 == SRUN). In top, see if they are
> chewing up lots of time.
Top doesn't update after the first mozilla process has started. Its
trace is:
mi_switch()
cv_timedwait_sig()
select()
syscall()
syscall_with_err_pushed()
--- syscall(93, .., select)
> > db> trace 517
> > mi_switch(0,cd193aa0,811f874,cd27cfa0,c02bead6) at mi_switch+0x1a0
> > _mtx_unlock_sleep(c039e860,0,c030b460,497) at _mtx_unlock_sleep+0x204
> > syscall(2f,2f,2f,811f874,1) at syscall+0x48a
> > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
> > --- syscall (514), eip = 0x285a31a7, esp = 0x811f858, ebp = 0x811f9b4 ---
>
> Weird syscall number (514). This one was blocked on a mutex that was just
> released. I'm betting that 0xc039e860 is Giant? Perhaps not though?
Rien ne va plus! It is Giant.
> > db> trace 520
> > mi_switch(cd193ee0) at mi_switch+0x1a0
> > userret(cd193ee0,cd257fa8,0,208,befffc00) at userret+0x395
> > syscall(2f,2f,2f,befffd24,befffc00) at syscall+0x3c9
> > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
> > --- syscall (0, Linux ELF, nosys), eip = 0x285b8bd4, esp = 0xbefffb24, ebp =
> > 0xbefffbf4 ---
>
> Another instance of being preempted upon return to userland. Possible that the
> regs in the trapframe are altered to hold return values and thus that the
> syscall number is invalid. Hmmmmmm.
That certainly would explain it (see above).
> What locks do all these processes hold?
No locks are hold by any of the processes. The question then is: what
are they waiting for?
I started playing with remote debugging let me look around for a bit.
BTW: Do we have handy functions for use in the remote debugger, such
as show_proc, show_vm or whatever, that dump important information
in a readable form?
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
