Unexpected panics

[Anthony V. Discolo]

> We are experiencing a semi-persistant and annoying (at the very least)
> problem with getting "panic: munhash" when debugging (usually large programs).
> Upon examination of the vmcore file generated it would seem the problem
> comes when the system wants to change the protection on a text page of
> the child process, probably for the purpose of altering the instruction
> where a breakpoint existed, however it isn't necessarily clear. We are
> running 4.2BSD on a 750 with 2Mbytes. The programs being debugged are on
> the order of at least 1/2Mbyte in size. For anyone who would like to
> tackle this problem, I am providing the (short) traceback below.

This is a pretty common 4.xBSD bug.  The following is a BSD bug
report that I've had around for a while:

%%% BEGIN BUG REPORT %%%
Return-Path: <mjb%Brown at UDel-Relay>
Received: from ucbvax.ARPA by ucbarpa.ARPA (4.10/4.7)
	id AA23877; Thu, 6 Oct 83 15:13:57 PDT
Received: from udel-relay.ARPA by ucbvax.ARPA (4.12/4.7)
	id AA17869; Mon, 3 Oct 83 11:42:44 PDT
Message-Id: <8310031842.AA17869 at ucbvax.ARPA>
Date:     3 Oct 83 (Monday) 03:06 EDT
From: Mike Braca <mjb%Brown at UDel-Relay>
Return-Path: <mjb%Brown at UDel-Relay>
Subject:  Using sdb or dbx can crash the system (panic: munhash)
To: 4bsd-bugs at BERKELEY
Via:  Brown; 3 Oct 83 13:21-EDT

Index:	sys/vax/vm_machdep.c 4.1c Fix
Description:
	You can crash the system using breakpoints in sdb or dbx
	(causing "panic: munhash").  Because of a bug in the compiler,
	incorrect code is generated in vax/vm_machdep.c. The compiler
	error is that a bit field which is declared as "unsigned int"
	gets its sign extended when it is cast to "long". The code
	affected is in routine chgprot() and is a parameter passed in a
	call to munhash() which reads:
		(daddr_t)c->c_blkno
	where "daddr_t" is typedef'ed to "long", "c" is a pointer to a
	"cmap" structure, and "c_blkno" is a 20-bit "unsigned int"
	field. If the file system is > 256MB, then the MSB of the bit
	field can be on, and what is passed to munhash() is a negative
	block number which it won't find, so it panics.
Repeat-By:
	This is real tough to repeat. First you need a file system
	that's larger than 256MB. Then you need an executable binary
	file that resides in blocks numbered higher than 256MB on that
	fs. Run sdb or dbx on the file and use breakpoints. The system
	will crash when it's trying to make one of the text blocks
	writeable in order to set the breakpoint.

	Just look at the assembly language produced by compiling
	vm_machdep.c , or disassemble the code using adb.  Notice that
	an "extv" instruction is generated to extract c->c_blkno in the
	mentioned case, rather than "extzv".
Fix:
	Fix the compiler! Or do this:
	*** vm_machdep.c.ucb	Fri Dec 17 14:57:33 1982
	--- vm_machdep.c	Wed Aug 24 03:33:08 1983
	***************
	*** 117,123
		if (pte->pg_fod == 0 && pte->pg_pfnum) {
			c = &cmap[pgtocm(pte->pg_pfnum)];
			if (c->c_blkno && c->c_mdev != MSWAPX)
	! 			munhash(mount[c->c_mdev].m_dev, (daddr_t)c->c_blkno);
		}
		*(int *)pte &= ~PG_PROT;
		*(int *)pte |= tprot;

	--- 117,124 -----
		if (pte->pg_fod == 0 && pte->pg_pfnum) {
			c = &cmap[pgtocm(pte->pg_pfnum)];
			if (c->c_blkno && c->c_mdev != MSWAPX)
	! 			munhash(mount[c->c_mdev].m_dev,
	! 				(daddr_t)((u_long) 0 + c->c_blkno));
		}
		*(int *)pte &= ~PG_PROT;
		*(int *)pte |= tprot;
	====END OF FIX====
%%% END BUG REPORT %%%

This fix does seem to work, as we made this fix on our machines a 
while back and haven't seen any panics of the munhash flavor since then.

--
uucp: ucbvax!ucsbcsl!discolo
arpa: ucsbcsl!discolo at berkeley
csnet: discolo at ucsb
USMail: Computer Systems Lab
	U.C. Santa Barbara
	Santa Barbara, CA  93106