Bob Dalesio wrote:
>
> I think it would be nice if the record was able to detect this
> and set it's status to BAD_CALC and not take a dirt nap. Do you
> have a copy of the expression that did the dirty deed.
>
> Bob
Done. This will be in next 3.13 release.
The fix involved adding one to all defines in post.h
so that it could start:
#define BAD_EXPRESSION 0
#define FETCH_A 1
#define FETCH_B 2
#define FETCH_C 3
postfix.c and calcPerform were changed to use BAD_EXPRESSION.
This means that ANY record type that uses calcPerform should
work if it meets two conditions:
1) The array holding the reverse polish notation is initialized
to start with a null. (This is automatically done if a field
defined in the dbd file is used).
2) The record type checks the return code from calcPerform, i.e.
it has code similar to the following:
if(calcPerform(&pcalc->a,&pcalc->val,pcalc->rpcl)) {
recGblSetSevr(pcalc,CALC_ALARM,INVALID_ALARM);
} else pcalc->udf = FALSE;
What made things crash before was:
1) FETCH_A was defined to be 0
2) The array holding the rpn was initialized to nulls.
This meant that calcPerform got something that looked
like an expression starting with a bunch (at least 200) of FETCH_A.
I did not look hard enough to see what happened next but I can
imagine really bad things.
Marty Kraimer
- References:
- Re: Bad CALC record kills IOC Bob Dalesio
- Navigate by Date:
- Prev:
Re: Bad CALC record kills IOC Marty Kraimer
- Next:
SGL encoder in EPICS Noboru Yamamoto
- 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: Bad CALC record kills IOC Bob Dalesio
- Next:
Re: Bad CALC record kills IOC Bob Dalesio
- 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
|