EPICS Controls 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  2020  2021  2022  2023  2024  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  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: caGateway crashes / use of *MustSucceed functions
From: Michael Davidsaver <[email protected]>
To: [email protected]
Date: Wed, 18 May 2011 09:56:05 -0400
On 5/18/2011 8:51 AM, Benjamin Franksen wrote:
On Wednesday, May 18, 2011, Dirk Zimoch wrote:
I got several caGateway crashes with the error message:
"errSymBld callocMustSucceed failed count 256 size 4"
Obviously it has some memory problems.

But is it really a good idea to abort a server only because of (probably
temporary ?) resource problems? I think no.
I think we all agree on that!

+1

I would even go so far to
say that the whole idea of the *MustSucceed functions is wrong. Many
parts of EPICS are meant to run continuously as servers. Aborting the
program when something goes wrong is probably the worst thing one can
do. Thus I would consider any call of a *MustSucceed function during
run-time a design flaw of the program.
Right.

(It is probably a different
question if this makes sense during startup.)
I am fairly sure that this is exactly what *MustSucceed was invented for.

How about a nice big warning in cantProceed.h? Something to the effect of "Don't use this unless you understand the consequences for your users".

Personally, I'm inclined to deprecate them just to remove the temptation to use them at runtime. I doubt there are any cases where they are more then a convenience.

Therefore I propose to remove all *MustSucceed functions from future
EPICS releases and allow and require proper error handling by the
application.
The use of these functions during startup is legitimate. Using them during
run-time is an error. The error in this case seems to be in the function
errSymBld which should not use callocMustSucceed.

See attached patch which adds a warning when *llocMustSucceed is called after iocInit(). For some fun try this with the softIoc executable. Things to try: Just press enter at the ioc shell, and do a caget.


Michael

diff --git a/src/libCom/misc/cantProceed.c b/src/libCom/misc/cantProceed.c
index 832622a..e84c3e7 100644
--- a/src/libCom/misc/cantProceed.c
+++ b/src/libCom/misc/cantProceed.c
@@ -20,6 +20,8 @@
 #include "cantProceed.h"
 #include "epicsThread.h"
 
+static int warnMust = 0;
+
 epicsShareFunc void * callocMustSucceed(size_t count, size_t size, const char *msg)
 {
     void * mem = NULL;
@@ -33,6 +35,10 @@ epicsShareFunc void * callocMustSucceed(size_t count, size_t size, const char *m
             epicsThreadSuspendSelf();
         }
     }
+    if(warnMust) {
+        errlogPrintf("Warning: callocMustSucceed(%lu, %lu) - %s - Called after init\n",
+                (unsigned long)count, (unsigned long)size, msg);
+    }
     return mem;
 }
 
@@ -49,6 +55,10 @@ epicsShareFunc void * mallocMustSucceed(size_t size, const char *msg)
             epicsThreadSuspendSelf();
         }
     }
+    if(warnMust) {
+        errlogPrintf("Warning: mallocMustSucceed(%lu) - %s - Called after init\n",
+            (unsigned long)size, msg);
+    }
     return mem;
 }
 
@@ -68,3 +78,9 @@ epicsShareFunc void cantProceed(const char *msg, ...)
     while (1)
         epicsThreadSuspendSelf();
 }
+
+epicsShareFunc void warnMustSucceed(void)
+{
+    errlogPrintf("> warnMustSucceed <\n");
+    warnMust = 1;
+}
diff --git a/src/libCom/misc/cantProceed.h b/src/libCom/misc/cantProceed.h
index 9f4dc1c..697fd10 100644
--- a/src/libCom/misc/cantProceed.h
+++ b/src/libCom/misc/cantProceed.h
@@ -22,6 +22,9 @@ epicsShareFunc void cantProceed(const char *errorMessage, ...);
 epicsShareFunc void * callocMustSucceed(size_t count, size_t size, const char *errorMessage);
 epicsShareFunc void * mallocMustSucceed(size_t size, const char *errorMessage);
 
+/* Call this once */
+epicsShareFunc void warnMustSucceed(void);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/misc/iocInit.c b/src/misc/iocInit.c
index 3100ffd..56cf6bc 100644
--- a/src/misc/iocInit.c
+++ b/src/misc/iocInit.c
@@ -151,6 +151,7 @@ int iocBuild(void)
 
     iocState = iocBuilt;
     initHookAnnounce(initHookAfterIocBuilt);
+
     return 0;
 }
 
@@ -179,6 +180,7 @@ int iocRun(void)
         "IOC restarted");
     iocState = iocRunning;
     initHookAnnounce(initHookAfterIocRunning);
+    warnMustSucceed();
     return 0;
 }
 

References:
caGateway crashes / use of *MustSucceed functions Dirk Zimoch
Re: caGateway crashes / use of *MustSucceed functions Benjamin Franksen

Navigate by Date:
Prev: Re: caGateway crashes / use of *MustSucceed functions Benjamin Franksen
Next: Re: caGateway crashes / use of *MustSucceed functions J. Lewis Muir
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  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: caGateway crashes / use of *MustSucceed functions Benjamin Franksen
Next: Re: caGateway crashes / use of *MustSucceed functions J. Lewis Muir
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  2020  2021  2022  2023  2024 
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 ·