Experimental Physics and
Industrial Control System

Andrew Johnson via Core-talk <[email protected]> · Mon, 19 Aug 2019 18:14:24 -0000

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.

-- 
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1840500

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

Status in EPICS Base:
  Confirmed
Status in EPICS Base 3.15 series:
  New
Status in EPICS Base 3.16 series:
  Won't Fix
Status in EPICS Base 7.0 series:
  Confirmed

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1840500/+subscriptions

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System