Date: Tue, 11 Feb 1997 14:09:16 -0500 From: guhl@mitre.org (George Uhl) To: freebsd-hackers@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org Subject: Fix to Interrupt/Terminate Signal causes page fault in kernel mode Message-ID: <v02130502af24f1e8a696@[128.29.114.90]>
next in thread | raw e-mail | index | archive | help
I posted the following to freebsd-hackers and freebsd-bugs a couple
of days ago. I have fixed the problem, not by making any code
changes, but by compiling the kernel unoptimized!
compiler: GNU gcc version 2.6.3
I question the wisdom of allowing the COPTFLAGS option in
/sys/386/conf/Makefile.i386 to enable optimization when
this may cause unpredictable and erroneous kernel behavior.
Any opinions?
BEGIN previous message:
I'm porting a version of OSI and X.25 from a heavily modified BSDI
ver1.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?
END previous message
----
George Uhl <guhl@mitre.org>
The MITRE Corporation
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02130502af24f1e8a696>