epics/pcas
0
0
Fork 0
Code Issues Pull Requests Projects Wiki Activity

added two bug fix descriptions

Browse Source
This commit is contained in:
Jeff Hill
2003-09-10 20:45:56 +00:00
parent 245cf129ff
commit dd273da508
1 changed files with 33 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
documentation/RELEASE_NOTES.html
View File

@@ -23,6 +23,39 @@
<p>The IOC shell now uses the vxWorks ledLib routines so command-line editing
is now the same in the IOC shell as it is in the vxWorks shell.</p>
<h4>CA client library crashes when the same PV name is on multiple server</h4>
<p>If the CA client library was searching for a PV name that is hosted by
more than one server a segmentation violation occurred when printing a
diagnostic message resulting in a failure of the CA client library. The bug
was intrioduced in R3.14.3. The code was tested on WIN32 prior to release.
The problem has so far been reproduced only on Linux. </p>
<p>Thanks to Ernest Williams at the SNS for discovering and helping to
diagnose the problem.</p>
<h4>Disconnection callback function called when CA channel known to be
disconnected</h4>
<p>If a CA circuit timed out during the connect sequence then the CA client
library called the applications's disconnect callback function indicating a
disconnect state transition when the channel was already known to be
disconnected. This has caused the sequencer to improperly maintain its
connected channel count. Other CA client side tools may also be impacted.</p>
<p>This problem is exacerbated by the fact that recent versions of vxWorks
appear to experience a connect failure if the vxWorks IP kernel reassigns the
same ephemeral TCP port number as was assigned during a previous lifetime.
The IP kernel on the vxWorks system hosting the CA server might have a stale
entry for this ephemeral port that has not yet timed out which prevents the
client from connecting with the ephemeral port assigned by the IP kernel.
Eventually, after EPICS_CA_CONN_TMO seconds, the TCP connect sequence is
aborted and the client library closes the socket, opens a new socket,
receives a new ephemeral port assignment, and successfully connects.</p>
<p>Thanks to Mark Rivers for initially reporting the bug and energetically
assisting with identifying the cause.</p>
<center>
<h2>Changes since 3.14.2</h2>
</center>