caget and cainfo return no data for any PV when one PV in arguments does not respond

Bug #1840500 reported by Glenn Horton-Smith
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
EPICS Base
Status tracked in 7.0
3.15
New
Low
Unassigned
3.16
Won't Fix
Low
Unassigned
7.0
Confirmed
Low
Unassigned

Bug Description

Starting with EPICS 3.15.6, also in 3.16.* and 7.*, the cainfo and caget tools no longer return information on any PV if one of the PVs in a list does not respond. This is different from version 3.15.5 and earlier, in which cainfo and caget would return information on all PVs specified, noting those that did not respond.

Example caget in version 3.15.5:

$ caget Mu2e_Weather_1/temperature_degF Mu2e_Weather_2/temperature_degF Mu2e_Weather_1/temperature_degC

Channel connect timed out: some PV(s) not found.
Mu2e_Weather_1/temperature_degF 82.1742
Mu2e_Weather_2/temperature_degF 80.615
Mu2e_Weather_1/temperature_degC *** not connected

Example caget in version 3.15.6:

$ caget Mu2e_Weather_1/temperature_degF Mu2e_Weather_2/temperature_degF
Mu2e_Weather_1/temperature_degC

Channel connect timed out: some PV(s) not found.

A similar difference is seen in cainfo. In 3.15.5, it will print out info for all the specified PVs, including "never connected" status for the missing PVs. In 3.15.6 and later, it just prints "some PV(s) not found."

This new behavior is less useful than the original behavior.

The cause of the change seems to be a small change in caget.c and cainfo.c. Here is a diff, with "<" being 3.15.5 and ">" being 3.15.6.

544c544
< connect_pvs(pvs, nPvs);
---
> result = connect_pvs(pvs, nPvs);
547,548c547,548
<
< result = caget(pvs, nPvs, request, format, type, count);
---
> if (!result)
> result = caget(pvs, nPvs, request, format, type, count);

The identical change was made in cainfo.c.

The original behavior was preferable, but if there is some good reason for not calling "caget" on PVs that failed to connect, then hopefully there is some way of handling that in the caget() function rather than just completely failing to do anything if even a single PV does not respond.

Revision history for this message
Bruce Hill (bhill) wrote :

Glenn, thanks for reporting this.
I've been seeing the same thing and it's annoying to not get the valid responses due to a single timeout.

pvget and pvinfo follow the same pattern.

Revision history for this message
mdavidsaver (mdavidsaver) wrote :

Confirmed. I hadn't noticed this.

@Bruce, Did you mean to say 'caget'? Current pvget et al. print values as they arrive, and so don't have this issue.

Changed in epics-base:
status: New → Confirmed
Revision history for this message
mdavidsaver (mdavidsaver) wrote :

The relevant commit is f2e54be965d14c62d879971807ee691f3a3c0c5d

Revision history for this message
Andrew Johnson (anj) wrote :

It looks like either an empty string or a too-long name were causing the SEGFAULT that the commit was protecting against — when a call to ca_create_channel() in tool_lib.c::create_pvs() fails and doesn't return a real chid, the caget() and cainfo() routines were still operating on the non-existent chid.

The pvs arrays in both programs are allocated using calloc() so this simple test for a NULL chid could be added to the cainfo() and caget() routines at the top of the for() loop to prevent a SEGFAULT:
    if (!pvs[n].chid) continue;
I would have made those changes myself just now if that was the only fix needed, but it isn't.

The connect_pvs() routine in tool_lib.c returns immediately without calling ca_pend_io() if its call to create_pvs() returned non-zero, so a bad PV name will still cause problems, preventing connections to other PVs on slower or remote IOCs. The create_pvs() routine is also called from camonitor.c so changing the semantics of its return value needs care to avoid breaking that.

Revision history for this message
Bruce Hill (bhill) wrote :

@mdavidsaver, you're right, this issue isn't the same in pvget/pvinfo.
Those apps do print out info for connected channels, but the output can
get intermixed, particularly w/ pvinfo.

Revision history for this message
Andrew Johnson (anj) wrote :

Looks like another bug that didn't get fixed.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.