Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ll-xn!adelie!munsell!pac
From: pac@munsell.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Sun OS obscure error message query - (nf)
Message-ID: <1028@pinney.munsell.UUCP>
Date: Mon, 11-May-87 18:01:02 EDT
Article-I.D.: pinney.1028
Posted: Mon May 11 18:01:02 1987
Date-Received: Thu, 14-May-87 03:30:03 EDT
References: <10@citcom.UUCP> <8200007@iaoobelix.UUCP> <752@mcgill-vision.UUCP>
Reply-To: pac@pinney.UUCP (Paul Czarnecki)
Organization: Eikonix Corp., Bedford, MA
Lines: 25
Summary: fixed in release 3.2

In article <752@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
>I have gotten this message [text table full] under circumstances that
>convince me that the Sun kernel (version 3.0, at least) loses slots,
>that is, it will sometimes leave them marked as in use when they
>really aren't, so eventually there are none left even if there aren't
>many processes running. 

Yes, I have seen this also under 3.0.  I was finally able to repeat it
reliably by: running dbx, running a program, stopping at a breakpoint,
re-compiling it, and running it again without first telling dbx to
"kill" it.

Sun agreed with me that it was there, that it wasn't a known dbx bug,
and that it wasn't there under 3.2.  (This implies that the bug lived
elsewhere and dbx just happened to expose it, it also implies that
there are other ways to lose slots)

dbx no longer has this failing under 3.2, so I presume the bug was
fixed.

					pZ

-- 
           Paul Czarnecki -- USENET, It's not just a job, but an adventure.
	{{harvard,ll-xn}!adelie,{decvax,allegra,talcott}!encore}!munsell!pz