From owner-freebsd-current Fri Sep 7 0:38:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 3C27937B401; Fri, 7 Sep 2001 00:38:55 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f877csf08398; Fri, 7 Sep 2001 00:38:54 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f877d0s18015; Fri, 7 Sep 2001 00:39:00 -0700 (PDT) (envelope-from marcel) Date: Fri, 7 Sep 2001 00:38:59 -0700 From: Marcel Moolenaar To: John Baldwin Cc: current@FreeBSD.org Subject: Re: Linuxulator: possible Giant pushdown victim Message-ID: <20010907003859.A446@dhcp01.pn.xcllnt.net> References: <20010905172451.A526@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.21i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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