Warning: 'Busy.PUTF' found true with PACT false

[Andrew Johnson]

From Mark Rivers:

I have now reproduced the problem with a simple 6 record database (attached). This database can be run on any IOC that is built with the busy record. A simple one is busy/busyApp/src/testBusyAsyn.cpp. That IOC also requires asyn, but this database does not.

The database works as follows:

bo record Acquire. Writing 1 to this record is what will trigger the problem.

bi record Acquire_RBV. This record is written to by Acquire. It is set to 0 by Reset. It is monitored by ClearBusy.

calcout record SetBusy. This record is FLNKd by Acquire and gets its value from Acquire. On transition to 1 it sets Busy to 1. It FNLKs to Reset.

busy record Busy. The value 1 is written to this record by SetBusy and the value 0 is written to it by ClearBusy. The busy record is basically a clone of the bo record except that it only calls RecGblFwdLink when its value is 0.

seq record Reset. This record processed when 1 is written to Busy. It has a delay of 1 second, and after that time it writes 0 to Acquire_RBV. It is disabled if Busy is 0 to avoid infinite loop.

calcout record ClearBusy. This record monitors Acquire_RBV. On that PV transitioning from 1 to 0 it writes 0 to the Busy record. I believe it is this write operation that is causing the error in EPICS base.

This is the error from EPICS base 7.0.2 after I also added a call to epicsStaceTrace() in addition to the errlogPrintf.

epics> Dumping a stack trace of thread 'scanOnce':
[ 0x7f49751f113b]: /usr/local/epics-devel/base-7.0.2/lib/linux-x86_64/libCom.so.3.17.2(epicsStackTrace+0x4b)
[ 0x7f49756b7057]: /usr/local/epics-devel/base-7.0.2/lib/linux-x86_64/libdbCore.so.3.17.2(dbDbPutValue+0x107)
[ 0x7f49756bac19]: /usr/local/epics-devel/base-7.0.2/lib/linux-x86_64/libdbCore.so.3.17.2(dbPutLink+0x29)
[ 0x7f497592f8a8]: /usr/local/epics-devel/base-7.0.2/lib/linux-x86_64/libdbRecStd.so.3.17.2(execOutput+0x88)
[ 0x7f497592ff29]: /usr/local/epics-devel/base-7.0.2/lib/linux-x86_64/libdbRecStd.so.3.17.2(process+0x589)
[ 0x7f49756a91c8]: /usr/local/epics-devel/base-7.0.2/lib/linux-x86_64/libdbCore.so.3.17.2(dbProcess+0x1d8)
[ 0x7f49756bcb37]: /usr/local/epics-devel/base-7.0.2/lib/linux-x86_64/libdbCore.so.3.17.2(onceTask+0x87)
[ 0x7f49751eb7bc]: /usr/local/epics-devel/base-7.0.2/lib/linux-x86_64/libCom.so.3.17.2(start_routine+0xdc)
[ 0x7f49743aae25]: /lib64/libpthread.so.0(start_thread+0xc5)
[ 0x7f49746bdbad]: /lib64/libc.so.6(clone+0x6d)
Warning: 'testBusyAsyn:Busy.PUTF' found true with PACT false

[mdavidsaver (mdavidsaver)]

https://epics.anl.gov/core-talk/2018/msg00911.php

I think the warning you see has served its purpose and can be removed,
or made conditional on dbAccessDebugPUTF. This condition is inevitable
if record support process() is allowed to return PACT=0 without
calling recGblFwdLink()

The real issue is that you should be seeing this warning both with and
without '-c'. That you do not is a symptom of dbNotify never setting PUTF.
While it wasn't immediately clear to me, dbPutField() is only used for link fields.
In other cases, the logic of dbPutField() is partially replicated in dbNotify.c
with calls to dbPut() and dbProcess().

[mdavidsaver (mdavidsaver)]

Also from Mark. A related, and more serious, regression related to the PUTF/RPRO change.

On 1/23/19 3:50 PM, Mark Rivers via Core-talk wrote:> Folks,
>
>
>
> I updated from 7.0.1 (actually some commit between 7.0.1) to 7.0.2. We discovered today that a very old database that has worked fine for 15 years stopped working. It is a database to run Pico Motors, which are piezo actuators controlled via RS-232. I have attached the database, and it is also on Github here: https://github.com/epics-modules/ip/blob/master/ipApp/Db/picoMotor.db .
>
>
>
> The device can only work in relative moves in steps.
>
>
>
> For this discussion the problem can be restricted to these 3 records.
>
>
>
> _pos is an absolute drive field. We write to that from CA clients. It writes to the _rel record with PP.
>
>
>
> _rel is a transform record that computes the relative move amount. It forward links to the _lim field, and sends the computed relative move to the _trunc record, which eventually sends it to the device.
>
>
>
> _lim is a limit checking record. It compares _pos to software limit values and sets high and low limit flags if they are exceeded.
>
>
>
> grecord(ao,"$(P)$(S):$(D):pM$(M)_pos") {
>
> field(DESC,"PicoMotor Position in EGUs")
>
> field(DTYP,"Soft Channel")
>
> field(SDIS,"$(P)$(S):$(D):pM$(M)_movn.VAL NPP NMS")
>
> field(FLNK,"0")
>
> field(OUT,"$(P)$(S):$(D):pM$(M)_rel.A PP MS")
>
> field(PREC,"3")
>
> }
>
>
>
> grecord(transform,"$(P)$(S):$(D):pM$(M)_rel") {
>
> field(DESC,"Convert EGUs to rel steps")
>
> field(FLNK,"$(P)$(S):$(D):pM$(M)_lim.PROC")
>
> field(CLCD,"(A>B)?(A-B):(A<B)?(-1*(B-A)):0")
>
> field(CLCE,"NINT((1/C)*D)")
>
> field(CLCF,"A")
>
> field(CLCH,"G=0?E:G=1?((-1)*E):E")
>
> field(INPA,"0")
>
> field(INPB,"$(P)$(S):$(D):pM$(M)_prev.VAL NPP MS")
>
> field(INPC,"$(P)$(S):$(D):pM$(M)_res.VAL NPP MS")
>
> field(INPG,"$(P)$(S):$(D):pM$(M)_dir.VAL NPP MS")
>
> field(OUTC,"0")
>
> field(OUTD,"0")
>
> field(OUTE,"0")
>
> field(OUTF,"$(P)$(S):$(D):pM$(M)_prev.VAL PP MS")
>
> field(OUTG,"0")
>
> field(OUTH,"$(P)$(S):$(D):pM$(M)_trunc.A PP MS")
>
> field(PREC,"6")
>
> field(CMTC,"user input EGUs/step")
>
> field(CMTD,"rel change in EGUs")
>
> field(CMTE,"rel change in steps")
>
> }
>
>
>
> grecord(transform,"$(P)$(S):$(D):pM$(M)_lim") {
>
> field(CLCD,"A>=C?1:0")
>
> field(CLCE,"A<=B?1:0")
>
> field(INPA,"$(P)$(S):$(D):pM$(M)_pos.VAL PP MS")
>
> field(INPB,"$(P)$(S):$(D):pM$(M)_pos.DRVL PP MS")
>
> field(INPC,"$(P)$(S):$(D):pM$(M)_pos.DRVH PP MS")
>
> field(OUTD,"$(P)$(S):$(D):pM$(M)_hi.VAL PP MS")
>
> field(OUTE,"$(P)$(S):$(D):pM$(M)_lo....

[mdavidsaver (mdavidsaver)]

Fixed by https://code.launchpad.net/~epics-core/epics-base/+git/Com/+merge/361381