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
<2003>
2004
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
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|