Date: Fri, 07 Feb 1997 15:44:58 -0500 From: George Uhl <guhl@mitre.org> To: freebsd-hackers@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org Subject: Interrupt/Terminate Signal causes page fault in kernel mode Message-ID: <32FB9449.2781E494@mitre.org>
next in thread | raw e-mail | index | archive | help
I'm porting a version of OSI and X.25 from a heavily modified BSDI ver
1.1
to FreeBSD 2.1.6. I'm running an application with a TP4 socket (OSI's
version of a
reliable, connection-oriented transport-layer socket) that is causing
the kernel
to crash when it is interrupted/killed by a signal (control-c, kill -9,
etc.).
The application is waiting for comm traffic (e.g., is listening for a
connect,
or is connected and waiting for data) and it receives the signal. Then
the
kernel crashes with:
Fatal trap 12: page fault while in kernel mode
Fault virtual address = 0x8
Fault code = supervisor read, page not present
Instruction pointer = 0x8:0xf010d620
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32, 1, gran 1
processor eflags = Interrupt enabled, resume, IOPL = 0
current process = 259 (tisink)
interrupt mask =
kernel: type 12 trap. code=0
Stopped at _exit1+0xc4 [/sys/compile/PORT1/:163]: movl 0x8(%ebp),%esi
The source code statement (line 163 in /sys/kern/kern_exit.c) from the
kernel is:
if (SESS_LEADER(p)) {
which translates to:
if (p->p_session->s_leader == p) {
At this point register %ebp is NULL. p is the pointer to the process
descriptor for the
application. I've use ddb to examine the registers, when the fdfree
function is called
from exit1 the ebp register contains a pointer to the kernel stack plus
some offset.
Just prior to leaving fdfree and returning to exit1, ebp is set to
zero. The fdfree
function does a closef on the socket fd which in turn calls a detach
function in the
OSI TP code.
If I hack the exit1 function and put a statement like a printf or an
if(0); prior to
the call to untimeout or fdfree, the kernel doesn't crash. This seems
like a timing
problem to me, but I'm not sure who or what is messing around with my
process
descriptor pointer. The OSI TP detach function releases OSI protocol
data strcutures
(like the TP4 and CLNP protocol control blocks) and frees the socket. I
don't think
the problem is in the detach code. Does anyone have any ideas?
--
George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32FB9449.2781E494>