Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: RE: caGateway crashes / use of *MustSucceed functions
From: "Jeff Hill" <johill@lanl.gov>
To: "'Dirk Zimoch'" <dirk.zimoch@psi.ch>
Cc: "'EPICS Tech Talk'" <tech-talk@aps.anl.gov>
Date: Fri, 20 May 2011 10:30:29 -0600
So I also completely agree that assert should never be used in
out-of-resource situations, and if you see such situations in my code I will
be happy to fix them.

>From my perspective the cant-proceed calls are also bad practice in
out-of-resource situations. When there isn't enough resource then we should
nearly always take evasive action. One exception frequently cited is when
starting an IOC its maybe ok, but if this occurs in common library code then
it's probably going to be used inappropriately in other situations, and
surely eventually we will need to upgrade allowing online add and delete of
records and then it's less clear when iocInit starts and ends? Besides, from
an operational perspective, if an IOC is low on memory when it starts
perhaps we are grateful that it continues and somehow against all odds
finishes iocInit continuing to perform limited functions in a degraded mode.
Who knows, perhaps one iocInit started subsystem asks for a huge chunk of
memory - one much bigger than is needed for the ca clients to attach later
(so continuing might actually work)?

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925


> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
> On Behalf Of Dirk Zimoch
> Sent: Wednesday, May 18, 2011 9:35 AM
> To: J. Lewis Muir
> Cc: tech-talk@aps.anl.gov
> Subject: Re: caGateway crashes / use of *MustSucceed functions
> 
> J. Lewis Muir wrote:
> > On 5/18/11 7:21 AM, Dirk Zimoch wrote:
> >> Therefore I propose to remove all *MustSucceed functions from
> >> future EPICS releases and allow and require proper error
> >> handling by the application.
> >>
> >> Any opinions on this topic?
> >
> > Hi, Dirk.
> >
> > What about the *MustCreate, *MustWait, and *MustLock functions?
> >
> >   epicsEventMustCreate
> >   epicsEventMustWait
> >   epicsMutexMustCreate
> >   epicsMutexMustLock
> >   epicsThreadMustCreate
> >
> > On a related note, I didn't look at all of them, but some of
> > these (e.g. epicsEventMustWait) are implemented as macros that
> > just do an assert on the return status of the regular non-must
> > function.  Others (e.g. POSIX epicsEventMustCreate) are actual
> > functions, but they too just do an assert.  If assertions are
> > disabled, this will do nothing and hence seems broken to me.  No?
> 
> Hi Lewis,
> 
> Yes. This is know as a "Heisenbug" (or the opposite?): bugs that go away
> (or appear) as soon as you switch on debugging. The behavior of the
> program should not change when assertions are switched on.
> 
> The idea of assert is to catch situations that "can never happen", as a
> part of the defensive programming paradigm. This may show hidden
> programming errors.
> 
> It is not the idea of assert to handle run-time problems like missing
> external resources, e.g. heap memory.
> 
> Example: epicsEventMustWait fails if the event id is invalid. This is a
> good application of assert because it should never happen if the program
> is correct.
> 
> epicsEventMustCreate fails if the system is out of memory. This is a bad
> application of assert because it may fail due to external influences
> even though the program is correct. However, it would be a good
> application of abort, assuming it is only called during startup. But who
> knows? Better call epicsEventCreate and handle failing resources by
> passing a proper error code back to the caller. Using assert here is
> extremely bad because if assertion is disabled, the error is not handled
> at all and will cause problems later.
> 
> Dirk
> 
> 




Replies:
Re: caGateway crashes / use of *MustSucceed functions Dirk Zimoch
References:
caGateway crashes / use of *MustSucceed functions Dirk Zimoch
Re: caGateway crashes / use of *MustSucceed functions J. Lewis Muir
Re: caGateway crashes / use of *MustSucceed functions Dirk Zimoch

Navigate by Date:
Prev: RE: CA beacon routing error S_errno_ECONNREFUSED Jeff Hill
Next: RE: problem with gateway and softIoc running on same server Kevin Tsubota
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: caGateway crashes / use of *MustSucceed functions Dirk Zimoch
Next: Re: caGateway crashes / use of *MustSucceed functions Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·