EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Problem with dbCaLink task in 3.14.4
From: "Mark Rivers" <[email protected]>
To: "Peter Eng" <[email protected]>, "Steve Sutton" <[email protected]>, "Matt Newville" <[email protected]>
Cc: <[email protected]>
Date: Mon, 3 Nov 2003 00:28:43 -0600
Dear Marty and Jeff,

I have now proven that the problem I am seeing with the dbCaLink task crashing is a bug in base (3.14.4), not a problem with the sscan record.

Here are the conditions that create the problem:
- A database record has a CA link to a another record field in the same IOC with an SPC_* (i.e. SPC_MOD, SPC_CALC) attribute.
- The special() function in that record returns -1, rather than 0
- This will crash the dbCaLink task with the error I reported:
dbCaLink: A call to "assert ((epicsMutexLock((pca->lock))==epicsMutexLockOK))" failed in ..../dbCa.c at 757

Here is a simple test case that proves that the problem is in base, not in the sscan record, which is where I was originally seeing it.

Do the following:
- Modify the special() function in base3.14.4/src/rec/calcoutRecord.c as follows:
      case(calcoutRecordCALC):
        pcalc->clcv=postfix(pcalc->calc,pcalc->rpcl,&error_number);
        if(pcalc->clcv){
              recGblRecordError(S_db_badField,(void *)pcalc,
                        "calcout: special(): Illegal CALC field");
        }
        db_post_events(pcalc,&pcalc->clcv,DBE_VALUE);
        /* CHANGE THIS RETURN STATEMENT TO RETURN -1 */
        /* return(0); */
        return(-1);

This makes the special() function return -1 when it encounters a bad CALC field.  The sscan record and other records in our applications have always returned -1 from special() in the case of errors.  The Application Developer's Guide does not say what special() should return. I do notice that the records in base always return 0, unless it is a field that special() does not know how to deal with.

- Create the following simple database in exampleApp
record(stringout,"$(P)testStringOut") {
    field(VAL, "x - w + g")
    field(OUT,"$(P)testCalcOut.CALC CA MS")
}
record(calcout,"$(P)testCalcOut") {
    field(CALC, "A")
}

This database writes an invalid calculation to the CALC field of the calcout record.  The modified version of special() in the calcout record returns -1 in this case.

Process the stringout record in this database.  Here is the result:
*******************************
iocVxPPC604> dbpf "epics:testStringOut.PROC","1"
DBR_UCHAR:          1         0x1                 
value = 0 = 0x0
iocVxPPC604> filename="../recGbl.c" line number=88
Illegal field value PV: epics:testCalcOut  calcout: special(): Illegal CALC field

dbCaLink: A call to "assert ((epicsMutexLock((pca->lock))==epicsMutexLockOK))" failed in ..../dbCa.c at 757
Current time MON NOV 03 2003 00:03:16.275024653.
EPICS Release EPICS R3.14.4 $R3-14-4$ $2003/09/23 21:35:11$.
Please E-mail this message and the output from "tt (0x1b003a0)"
to the author or to [email protected]

iocVxPPC604> filename="../../../src/libCom/taskwd/taskwd.c" line number=170
task 0x1b003a0 suspended
********************************

So this is the cause of our problem.

Is is illegal for special() to return -1?  Why does it crash the dbCaLink task in such a strange way?

Thanks,
Mark


Navigate by Date:
Prev: RE: Problem with dbCaLink task in 3.14.4 Mark Rivers
Next: CA questions Liyu, Andrei
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Problem with dbCaLink task in 3.14.4 Mark Rivers
Next: RE: Problem with dbCaLink task in 3.14.4 Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·