Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 27 Sep 2017 16:43:44 -0500

Hi Michael,

Assuming the process_record_li() routine is for triggering record
processing after some I/O has been received, why is it unconditionally
setting pli->pact? This looks to me like a cross between an asynchronous
I/O completion routine (i.e. part of an asynchronous read_longin()
device support method) and something for triggering record processing.

It isn't thread-safe; it accesses two pli fields in the second if()
condition without holding the record's scan-lock, which has been illegal
in all Base versions for quite a long time. Is there an associated
longin device support that goes along with this?

Is the I/O operation the only thing that causes this record to process?
The fact that you're getting SCAN/INVALID alarms suggests that something
else is going on as well, but I can't tell what from just the code you
showed us.

This might have worked in 3.14.12, but since it isn't following the
rules so there is no guarantee what it will do in other versions.

Sorry to be so blunt,

- Andrew

On 09/27/2017 03:30 PM, Dunning, Michael wrote:
> After upgrading to Base 3.15.5, we are seeing what looks like
> double-processing of a certain custom record type.  It is from our
> device support for Bira Ethernet Power Supply Controllers. The problem
> is with this record:
> 
> record(longin, "ESB:BEND:2110:GainADCRaw")
> {
>     field(DESC, "ADC Gain Raw Data")
>     field(ASG,  "Internal")
>     field(DTYP, "EtherPSC")
>     field(INP,   "#L0 N0 P0 S50 @172.27.248.43")
>     field(FLNK, "ESB:BEND:2110:GainADC.PROC")
> }
> 
> 
> 
> When the IOC boots, the record has STAT: SCAN and SEVR: INVALID.  If
> we camonitor this record, it seems to be processed twice:
> 
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:15.648796 529
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:15.648796 529 SCAN INVALID
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:16.549097 534
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:16.549097 534 SCAN INVALID
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:17.449359 543
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:17.449359 543 SCAN INVALID
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:18.349763 549
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:18.349763 549 SCAN INVALID
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:19.250071 551
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:19.250071 551 SCAN INVALID
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:20.150256 549
> ESB:BEND:2110:GainADCRaw       2017-09-10 20:12:20.150256 549 SCAN INVALID
> 
> 
> 
> The double-processing explains the SCAN and INVALID states.
> 
> Here is the record processing routine from device support:
> 
> static void process_record_li( ETHERPSCNODE *node, int signal, long i )
> {
>     PSCRECORD           *PSCRecord;
>     struct longinRecord *pli;
>     struct rset         *prset;
> 
>     PSCRecord = &node->record[signal];
>     if ( ! (pli = (struct longinRecord*) PSCRecord->precord) ) return;
> 
>     if ( pli->val != i  ||  pli->udf  ||  PSCRecord->nsta )
>     {
>         PSCRecord->nsta = NO_ALARM;
>         PSCRecord->val.li = i;
>         prset = (struct rset *) pli->rset;
> 
>         dbScanLock( (struct dbCommon*) pli );
>         pli->pact = TRUE;
>         (*prset->process)( pli );
>         dbScanUnlock( (struct dbCommon*) pli );
>     }
> }
> 
> 
> 
> I confirmed that this problem doesn't occur with Base 3.14.12.4.  Does
> anyone have any idea why this record would be processed twice with
> Base-3.15?
> 
> 
> 
> 
> 
> Michael Dunning
> SLAC National Accelerator Laboratory
> 2575 Sand Hill Road
> Menlo Park, CA 94025
> (650) 926-5200
> 

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System