From owner-freebsd-current Thu Sep 6 11:55:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 27B2F37B42A for ; Thu, 6 Sep 2001 11:55:30 -0700 (PDT) Received: from laptop.baldwin.cx (john@[147.11.46.201]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA29725; Thu, 6 Sep 2001 11:55:22 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010905172451.A526@dhcp01.pn.xcllnt.net> Date: Thu, 06 Sep 2001 11:55:19 -0700 (PDT) From: John Baldwin To: Marcel Moolenaar Subject: Re: Linuxulator: possible Giant pushdown victim Cc: current@FreeBSD.org 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 06-Sep-01 Marcel Moolenaar wrote: > On Wed, Sep 05, 2001 at 02:47:28PM -0700, John Baldwin wrote: >> >> Yes, you can trace indiviudal processes though, using 'trace ', and I'm >> more curious about the traces of the Mozilla processes. > > Ok, here it is: > > db> ps > pid proc addr uid ppid pgrp flag stat wmesg wchan cmd > 520 cd193ee0 cd256000 4152 517 514 000002 2 > mozilla-bin > 519 cd197840 cd1ab000 4152 517 514 2000002 3 pause c17d3000 > mozilla-bin > 518 cd193880 cd270000 4152 517 514 000002 3 select c039bb24 > mozilla-bin > 517 cd193aa0 cd27b000 4152 514 514 000002 2 > mozilla-bin > 514 cd194100 cd244000 4152 505 514 004002 2 > mozilla-bin > ... Note that 3 of these are runnable (stat of 2 == SRUN). In top, see if they are chewing up lots of time. > db> trace 514 > mi_switch(cd194100) at mi_switch+0x1a0 > userret(cd194100,cd245fa8,c5,a,bfbfeae0) at userret+0x395 > syscall(2f,2f,2f,282397c0,bfbfeae0) at syscall+0x3c9 > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b > --- syscall (148, Linux ELF, linux_fdatasync), eip = 0x285c2074, esp = > 0xbfbfeac8, ebp = 0xbfbfeb98 --- It was returning from a syscall but had to do a context switch due to PS_NEEDRESCHED because it got preempted. > 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? > db> trace 518 > mi_switch(cd19399c,cd193880,0,2,0) at mi_switch+0x1a0 > cv_timedwait_sig(c039bb24,cd19399c,dad,1,bfbffeb8) at cv_timedwait_sig+0x65b > poll(cd193880,cd271f44,cd19399c,cd193880,bf3ffa4c) at poll+0x656 > linux_poll(cd193880,cd271f80,bf3ffa4c,88b8,bf3ffa4c) at linux_poll+0x11f > syscall(2f,2f,2f,bf3ffa4c,88b8) at syscall+0x339 > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b > --- syscall (168, Linux ELF, linux_poll), eip = 0x285c7894, esp = 0xbf3ff9e8, > ebp = 0xbf3ff9f4 --- Asleep in select as ps shows. > db> trace 519 > mi_switch(cd19795c,cd197840,c17d3000,c02f3a60,2) at mi_switch+0x1a0 > msleep(c17d3000,cd19795c,168,c02f0f49,0) at msleep+0x71a > sigsuspend(cd197840,cd1acf4c,cd1acf44,bfbffeb8,cd19795c) at sigsuspend+0x19f > linux_rt_sigsuspend(cd197840,cd1acf80,bf1ff94c,bf1ff94c,28239fc8) at > linux_rt_sigsuspend+0x8e > syscall(2f,2f,2f,28239fc8,bf1ff94c) at syscall+0x339 > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b > --- syscall (179, Linux ELF, linux_rt_sigsuspend), eip = 0x2851c656, esp = > 0xbf1ff92c, ebp = 0xbf1ff934 --- Asleep in pause as ps shows. > 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. What locks do all these processes hold? I would expect the ones in stat 3 (SSLEEP) to hold none, but the others might hold locks. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message