Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ncar!asuvax!hrc!gtephx!boylel
From: boylel@gtephx.UUCP (Lee Boyle  x4528)
Newsgroups: comp.sys.apollo
Subject: Re: DN4500 arbitrarily overloads itself (was Re: (none))
Summary: sfcb problem not completely cured in SR10.3
Message-ID: <1991Jun24.203155.1480@gtephx.UUCP>
Date: 24 Jun 91 20:31:55 GMT
References: <0677436884@INESCN.RCCN.PT> <DPASSAGE.91Jun20122344@soda.berkeley.edu> <1991Jun24.002623.18899@gtephx.UUCP>
Organization: gte
Lines: 30

In article <1991Jun24.002623.18899@gtephx.UUCP>, wilsonj@gtephx.UUCP (Jay Wilson) writes:
> Apollo claims the problem has been fixed at SR10.3, (I won't even get started on
> the extreme, orgasmic joy experienced when hearing this phrase)

  I've seen a couple of references to the fact that this problem has gone
  away under SR10.3.  That's almost true.  At least the one cause I know
  about seems to be preventable.  

  I was bitten by code which used pgm_$invoke to create a process running 
  /com/sh without bothering to connect a valid stream to errout.  Under 
  SR9.7, the error output just went into the bit bucket.  Under SR10.3,
  (quoting the APR response) "This caused other problems that compounded
  as execution progressed from that point."  These problems eventually led
  to the "unable to obtain SFCB mutex lock" error. 
  I interpret this to mean that my bit bucket now leaks into the table.

  I know of at least one other site that used the same technique under 9.7,
  and has been similarly bitten under SR10.3.  Caveat Hacker.

  Apollo says that it will be fixed in a future release.


 UUCP    : {ncar!noao!asuvax | uunet!zardoz!hrc | att}!gtephx!boylel
 INTERNET: gtephx!boylel@asuvax.eas.asu.edu

-- 
Lee Boyle (boylel@gtephx)
UUCP: {ncar!noao!asuvax | uunet!zardoz!hrc | att}!gtephx!boylel
AG Communication Systems, Phoenix, AZ
(602) 581-4528