diff --git a/RELEASE_NOTES.html b/RELEASE_NOTES.html index ad3176d49..16a1ab857 100644 --- a/RELEASE_NOTES.html +++ b/RELEASE_NOTES.html @@ -7,6 +7,29 @@ +

EPICS Release 3.13.9

+ +

Changes since 3.13.8

+ +

Assert fail in CA libraries when system runs low on mbufs

+ +

Scope

+ +

The bug exists in probably in all previous versions of EPICS.

+ +

Symptoms

+ +

An IOC, low on network buffers, prints a message about an assert failure. +The assert failure can cause the CA server or the CA client library to be +compromised depending on where in the code it occurs.

+ +

Fix

+ +

All calls to getpeername() and getsockname() were checked and fixed as +necessary to make certain that an assert() failure does not occur if failure +status is returned, and that a proper response is made to this off-normal +situation.

+

EPICS Release 3.13.8

Changes since 3.13.7

@@ -24,9 +47,9 @@ at elevated priority resulting from vxWorks priority inheritance scheduling. All attached CA clients will permanently disconnect from the IOC, and record processing may be disrupted if the threads priority is elevated. Elevated priority was observed in the one situation where the bug has been reproduced -and identified so far.

+and identified so far.

-

Circumstances Related to Relative Rates of Occurrence

+

Circumstances Related to Relative Rates of Occurrence

This bug will occur only in circumstances where the CA client deletes a monitor subscription and the client's CA event queue in iocCore is 100% full. @@ -36,7 +59,7 @@ subscriptions for a particular client are sending subscription update events at a rate that is faster than the client is reading them. Therefore, specialized clients that have a small number of regularly updated subscriptions and that do not regularly call ca_poll() or ca_pend_event() are -more likely to reproduce the problem.

+more likely to reproduce the problem.

Config Changes

long dbGetLink(struct db_link *,short dbrType,
-        void *pbuffer,long *options,long *nRequest);
+        void *pbuffer,long *options,long *nRequest); The last two arguments can be 0. options=0 means no options. nRequest=0 means scalar, i.e. retrieve one value. 
long dbPutLink(struct db_link *,short dbrType,
-        void *pbuffer,long nRequest);
+        void *pbuffer,long nRequest); @@ -1883,14 +1910,14 @@ All record instances must be capable of being loaded into an ioc via dbLoadDatabase, dbLoadRecords, or dbLoadTemplate. This is the same format that dbLoadRecords and dbLoadTemplate used in 3.12 releases. Note that if any files contain the statements: -
        database(x) { nowhere() {
-        }
-        }
+
        database(x) { nowhere() {
+        }
+        }
 
 or
 
-        database(x) {
-        }

+        database(x) {
+        }
These statements must be removed. They were in pre 3.12 releases.

CONSTANT Links with value "0"

@@ -1898,10 +1925,10 @@ Release 3.13 is now capably of distingushing between a null link (a link that is not given any value at all) and a constant link with the value 0. This cause problems for some old record instance files. For example if a record instance is defined as: -
        record(fanout,name) {
-                field(SELN,"1")
-                field(SELL,"0")
-        }
+
        record(fanout,name) {
+                field(SELN,"1")
+                field(SELL,"0")
+        }
Such definitions can be fixed by either completly removing the link definition or changing the value from "0" to "". @@ -1947,7 +1974,7 @@ problem:

A good way to find these problems is to use grep. For example: -
        grep SELL */*.db
+
        grep SELL */*.db
This assumes that you are in directory that contains subdirectorys containing .db files.