Date: Thu, 8 Jul 1999 11:28:10 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jerry Bell <jerry@bellnetworks.net> Cc: "Brian F. Feldman" <green@FreeBSD.ORG>, Andrew Gallatin <gallatin@cs.duke.edu>, Stephen McKay <syssgm@detir.qld.gov.au>, alc@cs.rice.edu, freebsd-current@FreeBSD.ORG Subject: Re: Stuck in "objtrm" - live kernel test to run Message-ID: <199907081828.LAA41802@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
Ok, I've traced the code down and I think that there is a good chance
that the OBJ_DEAD fix that Alan described may solve the problem.
What I think is happening is that a process context is holding a PIP
count on the object, then deallocating the object and creating an
interlock situation.
There is a way we can find out for sure. For any of you with processes
stuck in objtrm, see if you can gdb the kernel and get a backtrace
of that process to see if it might be in a state where a previous
call context is holding a PIP count on the object.
gdb -k /kernel /dev/mem
^^
works better if this is a debug kernel but it doesn't
have to be. It does have to be the kernel that is currently
running.
proc <PID> (e.g. proc 222)
^^^^
gdb's default radix is 10, but sometimes
people change it to 16 so if it complains,
you may be typing the number in in the
wrong radix.
back
Note: the process cannot be swapped out, so if you've had a process
stuck in objtrm for a long time try doing as "ps axfl" to force it's
upages in and then gdb should be able to backtrace it. The 'f' in the ps
does that.
-Matt
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?199907081828.LAA41802>