Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: kernal panic
Message-ID: <3042@sun.uucp>
Date: Thu, 28-Nov-85 15:44:10 EST
Article-I.D.: sun.3042
Posted: Thu Nov 28 15:44:10 1985
Date-Received: Fri, 29-Nov-85 21:03:38 EST
References: <1402@daemen.UUCP>
Distribution: na
Organization: Sun Microsystems, Inc.
Lines: 26

> We recently had the system panic twice within two hours with a
> "exit: m_getclr" panic.  Could anyone explain what causes this and how
> to prevent it.

When a process exits, its user area gets discarded; only its process table
entry remains behind (until its parent does a "wait" and reclaims its
corpse).  The process' exit status and user/system CPU time (and other
resource usage figures, in 4.xBSD) for it and its children have to remain
around.  In most versions of UNIX, this is squirreled away in the process
table entry (some fields in the process table entry which aren't used for
the corpse of a process are recycled for this purpose).  In 4.2BSD, however,
they allocate an "mbuf" to hold the resource usage.  "mbuf"s are memory
buffers also used by the networking code.  If the networking code has eaten
them all up for its own purposes, "exit" can't get an "mbuf" and,
annoyingly, panics.

The simplest fix is to have it just note the fact that it couldn't get an
"mbuf" and not bother remembering the resource usage information (and make
sure that if "p->p_ru", which is the pointer to the "mbuf" in question, is
NULL, you *don't* try to use the pointer, since it doesn't point to
anything!).  You might also want to see why you're runing out of "mbuf"s;
there may be some problem in your kernel or on your network.

Anybody know what 4.1BSD did, and why they would have used an "mbuf" in 4.2?

	Guy Harris