Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Sep 2001 00:38:59 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        current@FreeBSD.org
Subject:   Re: Linuxulator: possible Giant pushdown victim
Message-ID:  <20010907003859.A446@dhcp01.pn.xcllnt.net>
In-Reply-To: <XFMail.010906115519.jhb@FreeBSD.org>
References:  <20010905172451.A526@dhcp01.pn.xcllnt.net> <XFMail.010906115519.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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		 marcel@xcllnt.net

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010907003859.A446>