Skip site navigation (1)Skip section navigation (2)
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>