I looked and the following is happening.
When control limits are requested the following happens
0) db_access requests dbAccess to retrieve the control info.
1) dbAccess allocates space on the stack for the control limits as doubles. This
storage is NOT initialized. Thus it contains random garbage.
2) It calls the recort support get_control_double routine to get the control
limits
3) The calc record looks at which field is being requests. The HOPR field is not
one of the fields it accepts as having control limits. Thus it does nothing.
4) Old database access converts the doubles to float and the exception occurs
when the random garbage on the stack has bad values.
We did not see this happen on 68xxx because the floating point exceptions were
not raised. The powerPC does raise these exceptions. The good news is that we
can now find new bugs. The bad news is that it suspends the task. Sigh!!!
The same thing can happen when asking for graphics and alarm limits. Here are
some diffs to fix dbAccess.c for release 3.13.3.
diff -c -r1.89.4.3 dbAccess.c
*** dbAccess.c 2000/06/28 13:37:35 1.89.4.3
--- dbAccess.c 2000/08/24 21:34:09
***************
*** 198,203 ****
--- 198,204 ----
struct dbr_grDouble grd;
int got_data=FALSE;
+ grd.upper_disp_limit = grd.lower_disp_limit = 0.0;
if( prset && prset->get_graphic_double ) {
(*prset->get_graphic_double)(paddr,&grd);
got_data=TRUE;
***************
*** 237,242 ****
--- 238,244 ----
struct dbr_ctrlDouble ctrld;
int got_data=FALSE;
+ ctrld.upper_ctrl_limit = ctrld.lower_ctrl_limit = 0.0;
if( prset && prset->get_control_double ) {
(*prset->get_control_double)(paddr,&ctrld);
got_data=TRUE;
***************
*** 276,281 ****
--- 278,285 ----
struct dbr_alDouble ald;
int got_data=FALSE;
+ ald.upper_alarm_limit = ald.upper_warning_limit = 0.0;
+ ald.lower_warning_limit = ald.lower_alarm_limit = 0.0;
if( prset && prset->get_alarm_double ) {
(*prset->get_alarm_double)(paddr,&ald);
got_data=TRUE;
The change just involves initializing dbr_grDouble grd,dbr_ctrlDouble ctrld,
and dbr_alDouble ald.
This will be fixed in future releases.
Marty
Chip Watson wrote:
>
> There is a bug in the interaction of channel access and the IOC which
> only appears under unusual circumstances, but was stumbled into by CDEV
> code. The problem appeared when CDEV version 1.7.2 attempted to
> get the HOPR / LOPR field of a CALC record. (IOC running 3.13) The
> following was observed on the IOC at SLS:
>
> Floating point overflow
> Floating point inexact
> Exception current instruction address: 0x01a60838
> Machine Status Register: 0x0010b130
> Condition Register: 0x22000040
> Fp Control and Status Register: 0xd2028070
> Task: 0x18f0560 "CA client"
> filename="../taskwd.c" line number=175
> task 18f0560 CA client suspended
>
> I chased the problem back to exactly what CA client code causes this
> event and found that it comes from asking for the DBR_CNTL_FLOAT
> for the calc record.HOPR channel. This is of course an unusual thing to ask
> for, but happens if a slider (for example) is attached to the HOPR field of
> a CALC record using CDEV.
>
> In the meantime, we have patched the CDEV client code at PSI / SLS
> to not make this type of call (unless forced to by the caller) to avoid this
> problem. These mods will be included in CDEV 1.7.3, but can be obtained
> sooner if anyone else has experienced this problem.
>
> --
> Chip Watson
> High Performance Computing Group
> Thomas Jefferson National Accelerator Facility
> Tel: (757) 269-7101
> http://www.jlab.org/~watson
- References:
- bug Chip Watson
- Navigate by Date:
- Prev:
bug Chip Watson
- Next:
November Collaboration Meeting Leo 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
- Navigate by Thread:
- Prev:
bug Chip Watson
- Next:
November Collaboration Meeting Leo 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
|