From pb@fasterix.frmug.org  Sat Dec 20 07:12:25 1997
Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA21593
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 20 Dec 1997 07:12:22 -0800 (PST)
          (envelope-from pb@fasterix.frmug.org)
Received: (from uucp@localhost)
	by frmug.org (8.8.8/frmug-2.2/nospam) with UUCP id QAA08302
	for FreeBSD-gnats-submit@freebsd.org; Sat, 20 Dec 1997 16:12:18 +0100 (CET)
	(envelope-from pb@fasterix.frmug.org)
Received: (from pb@localhost)
	by fasterix.frmug.org (8.8.8/8.8.5/pb-19970302) id QAA01418;
	Sat, 20 Dec 1997 16:06:47 +0100 (CET)
Message-Id: <199712201506.QAA01418@fasterix.frmug.org>
Date: Sat, 20 Dec 1997 16:06:47 +0100 (CET)
From: Pierre Beyssac <pb@fasterix.freenix.org>
Reply-To: pb@fasterix.freenix.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: simple csh script panics kernel
X-Send-Pr-Version: 3.2

>Number:         5350
>Category:       kern
>Synopsis:       simple csh script panics kernel
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Dec 20 07:20:01 PST 1997
>Closed-Date:    Sat Apr 11 10:27:42 PDT 1998
>Last-Modified:  Sat Apr 11 10:27:55 PDT 1998
>Originator:     Pierre Beyssac
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
individual
>Environment:

December 19 -current, K6 64Mb RAM.

>Description:

The following csh script causes a kernel panic:

#!/bin/csh -f
nonexistentfile1
rm nonexistentfile2

The panic is a "supervisor read, page not present". I haven't been
able to obtain a crash dump, the fault address is generally 0, the
instruction pointer is sometimes 0 too. I haven't been able to
obtain a stack dump either even with a DDB-compiled kernel (DDB
gets a page fault in the "trace" command).

At least once, the instruction pointer was pointing to somewhere
near kernel function sigreturn (sigreturn+262 in my kernel, compiled
with -O), this happens to be the "d" in string "BIOS basemem (%ldK)".

>How-To-Repeat:

Run the script (it's a simplified version of a script taken from
Bochs which only seems to panic the machine once in every two
tries).

It even works in single-user mode, with just / mounted read only:
this should be quite easy to reproduce as it only seems to be an
interaction between csh and the kernel.

>Fix:

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Sat Apr 11 10:27:42 PDT 1998 
State-Changed-Why:  
doesn't crash current. 
>Unformatted:
