Bug in dbCa.c's doLocked breaks CA link disconnect detection
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
EPICS Base | Status tracked in 7.0 | |||||
3.16 |
Fix Released
|
Critical
|
Andrew Johnson | |||
7.0 |
Fix Released
|
Critical
|
Unassigned |
Bug Description
There is a bug in the doLocked function of dbCa.c: Due to the use of pcaGetCheck, the supplied callback does not get called when the CA channel is disconnected.
This causes a problem when using a CA link as the input to a soft record: The soft device support for the ai record (and most likely also the ones for the other records) does the following when the record is processed:
// ...
status = dbLinkDoLocked(
if (status == S_db_noLSET)
status = readLocked(
// ...
The readLocked function then calls dbGetLink for actually reading the value. However, when the link is a CA link and the channel is not connected, the implementation of dbLinkDoLocked for CA links does not actually call the callback and simply returns -1. This means that dbGetLink is never called and thus the processed record's alarm severity and status are never set to INVALID_ALARM and LINK_ALARM.
This bug is present in EPICS Base 3.16 (starting with 3.16-rc1) and 7.0. Earlier versions are not affected because the soft device support code in these version does not use dbLinkDoLocked and calls dbGetLink directly.
I attached a patch that fixed the problem in EPICS Base 7.0.1.1. Apart from changes to the path, this patch should also apply to EPICS Base 3.16.
Reproduced with
cat <<EOF >badlink.db
record(ai, "rec") {
field(INP, "invalid CA")
field(UDF, "0")
field(PINI, "RUNNING")
}
EOF
softIoc -d badlink.db
No alarm is active.