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: Andrew Johnson <anj@aps.anl.gov>
To: tech-talk@aps.anl.gov
Date: Wed, 18 May 2011 12:07:59 -0500
Hi Lewis,

On 2011-05-18 J. Lewis Muir wrote:
> 
> If assertions are enabled and the EPICS assert is being used,
> then epicsThreadSuspendSelf() will be called by all those
> functions I listed which use assert.  As Dirk pointed out, for
> some of these that's OK, so I shouldn't have listed them.  But
> for the *MustCreate functions, the thread will be suspended if
> the system is out of memory.

In most cases the *MustCreate() functions *are* being used at initialization 
time where the IOC can't actually start running if they fail; there they are 
appropriate.  I agree that we shouldn't be using them after iocInit() though, 
and I have been removing such cases as I find them.  I like Michael's patch 
that will warn us when this is occurring — it could be extended to include the 
*MustCreate() functions, but I do think it would only be appropriate to merge 
it into the 3.15 development tree and not into any production release.

However there are cases where completely solving this issue may be difficult 
because some of our standard APIs don't currently allow for a failure return 
status.  Changing those APIs will have knock-on effects on code both inside 
and outside of Base.

> And then there's my related note problem where the behavior is
> different depending on whether assertions are enabled.  For the
> *MustCreate functions, if assertions are enabled, the thread
> suspends if there's not enough memory.  If assertions are
> disabled, the application likely crashes somewhere else because
> the memory was not allocated.

Several years ago we acknowledged that building EPICS Base with assertions 
disabled would cause major problems, which is why the standard build system 
never does that.  I believe I have already removed all uses of assert() that 
contain active code, and I have an active merge proposal that removes assert() 
from the epicsEvent code and calls cantProceed() instead.  There may be some 
other areas that need similar cleanups, but assert() calls may legally appear 
in places where the assertion can only fire if there is a real bug in the 
code.

Thanks,

- Andrew
-- 
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham


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 Benjamin Franksen
Re: caGateway crashes / use of *MustSucceed functions J. Lewis Muir

Navigate by Date:
Prev: Re: caGateway crashes / use of *MustSucceed functions J. Lewis Muir
Next: Visit of SLAC/ALS control room? emmanuel_mayssat
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 J. Lewis Muir
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 ·