Date: Wed, 5 Sep 2001 17:24:51 -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: <20010905172451.A526@dhcp01.pn.xcllnt.net> In-Reply-To: <XFMail.010905144728.jhb@FreeBSD.org> References: <20010905135040.A398@athlon.pn.xcllnt.net> <XFMail.010905144728.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 05, 2001 at 02:47:28PM -0700, John Baldwin wrote: > > Yes, you can trace indiviudal processes though, using 'trace <pid>', 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 ... db> trace Debugger(c0305de9) at Debugger+0x44 scgetc(c039a080,2,c1667a00,c0392da0,4) at scgetc+0x412 sckbdevent(c0392da0,0,c039a080,c1667a00,c1669780) at sckbdevent+0x1c9 atkbd_intr(c0392da0,0,cc475f7c,c01bd99b,c0392da0) at atkbd_intr+0x22 atkbd_isa_intr(c0392da0) at atkbd_isa_intr+0x18 ithread_loop(c1669780,cc475fa8) at ithread_loop+0x2bf fork_exit(c01bd6dc,c1669780,cc475fa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 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 --- 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 --- 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 --- 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 --- 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 --- NOTE 1: process 517: this process seems to be the most active. Multiple breaks after continuing result in different traces. NOTE 2: process 518: there's no linux_poll in the source tree. This is a local change. NOTE 3: process 520: syscall 0 is an invalid Linux syscall (used to be setup()). NOTE 4: this is not reproducable on Alpha, because it panics even before loading mozilla, but this is for later. I'll go with my hunch (sp?) that it's linux_clone and see if I can find the evidence. The systems looks responsive, but everything that relates to processes (creation, destruction) seem to queue up. At least that's how it "feels"... FYI, -- 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?20010905172451.A526>