From owner-freebsd-bugs  Fri Feb  7 12:45:19 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id MAA18561
          for bugs-outgoing; Fri, 7 Feb 1997 12:45:19 -0800 (PST)
Received: from wacky.acet.org.noname ([192.188.104.18])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA18553;
          Fri, 7 Feb 1997 12:45:11 -0800 (PST)
Received: from wacky (localhost.acet.org) by wacky.acet.org.noname (4.1/SMI-4.1)
	id AA05464; Fri, 7 Feb 97 15:44:58 EST
Message-Id: <32FB9449.2781E494@mitre.org>
Date: Fri, 07 Feb 1997 15:44:58 -0500
From: George Uhl <guhl@mitre.org>
X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4m)
Mime-Version: 1.0
To: freebsd-hackers@FreeBSD.org
Cc: freebsd-bugs@FreeBSD.org
Subject: Interrupt/Terminate Signal causes page fault in kernel mode
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-bugs@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

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