EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  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  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: bug
From: Marty Kraimer <[email protected]>
To: Chip Watson <[email protected]>
Cc: [email protected]
Date: Thu, 24 Aug 2000 16:58:51 -0500
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  <20002001  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  <20002001  2002  2003  2004  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 ·