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

[Glenn Horton-Smith]

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.

[Bruce Hill (bhill)]

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.

[mdavidsaver (mdavidsaver)]

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.

[mdavidsaver (mdavidsaver)]

The relevant commit is f2e54be965d14c62d879971807ee691f3a3c0c5d

[Andrew Johnson (anj)]

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.

[Bruce Hill (bhill)]

@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.

[Andrew Johnson (anj)]

Looks like another bug that didn't get fixed.