All R3.14 versions of base up to and including R3.14.9 have a bug in the task watchdog code which can cause an IOC to segfault when a task gets suspended if a call to taskwdAnyInsert() has previously been used. This bug has already been fixed in R3.14.10 and it seems that not many sites have been using this facility of the task watchdog before now, so it has gone unnoticed, especially since it usually just converts a suspension event into a segfault a few seconds later. Thanks to Stephanie Allison for finding it. The fix is to make the following change to base/src/libCom/taskwd/taskwd.c:
Index: taskwd.c
===================================================================
--- taskwd.c 30 Mar 2006 19:52:35 -0000 1.11.2.2
+++ taskwd.c 6 Oct 2008 22:12:34 -0000
@@ -178,7 +178,7 @@ static void taskwdTask(void)
ptany = (struct task_list *)ellFirst(&anylist);
while(ptany) {
if(ptany->callback) {
- TASKWDANYFUNCPRR pcallback = pt->callback;
+ TASKWDANYFUNCPRR pcallback = ptany->callback;
(pcallback)(ptany->arg,pt->id.tid);
}
ptany = (struct task_list *)ellNext(&ptany->node);
Since R3.14.4 when the ability to drive device support was added to it, the
calcout record type has not implemented the IVOA action Don't drive
outputs
if an invalid alarm state is caused by one of the checks against
HIHI, HIGH, LOW or LOLO.
We are aware that there are a number of problems with IOCs built on 64-bit architectures (anywhere that a long is not 32 bits wide). Some of these will not be noticable on little-endian (x86_64) systems though. The changes required to fix this are not fully known yet and are likely to be fairly extensive, involving files in several different parts of Base, so we will not be issuing a patch file to correct this. We therefor do not recommend building IOCs on 64-bit platforms at this time, use the 32-bit target architecture instead. The CA client library currently looks Ok on 64-bit (but we can't vouch for the standard EPICS Extensions).
This problem was introduced in R3.14.9, so it does not apply to earlier releases — see the Mantis bug report for details. The fix requires applying this patch in the base/src/rsrv directory.
The Leopard release of Max OS X doesn't provide finite() any more, only the C99 isfinite() routine. Save this file as epicsMath.h in the base/src/libCom/osi/os/Darwin directory to build Base on Leopard.
Recent versions of RTEMS do not like the version of epicsMath.h found in base/src/libCom/osi/os/RTEMS. Replace that file with this version if you see that problem.
This issue will probably affect PV Gateway users most, but all server tools will exhibit the bug: Doing a caput of a string array to a portable server fails. Applying this patch in the base/src/cas/generic directory fixes the problem.
In Base R3.14.9 the breapoint table parser was enhanced and checks added to ensure that all breakpoint tables are strictly monotonic. This requirement is not necessary providing the table is only used in one direction, thus the check is overly broad and prohibits breaktable use in some circumstances where it is actually safe to do so ("safety" here must be determined by the application developer properly understanding how the cvtRawToEngBpt() and cvtEngToRawBpt() routines are used in the applicable record types). This patch (applied in the base/src directory) disables the check when the variable dbBptNotMonotonic has been set to a non-zero value.
Cygwin appears to have a bug on Windows Vista such that the stat() library function does not return the correct access permission information about files. This affects the makeBaseApp.pl script which uses Perl's -r operator to check for the existance and accessibility of template files and directories. Until this bug is fixed in Cygwin, the workaround is to edit the base/src/makeBaseApp/makeBaseApp.pl file and replace all -r tests with -e instead, which does work properly. This change will not be made in official releases of Base.
In "Specified" mode the select record support code does not test the value of the SELN field against its limits before using it, which can result in a crash. This patch contains a fix for src/rec/selRecord.c.
There is a memory leak in the CAS library which affects the PV Gateway and possibly other CA server tools. The fix for this is to apply this patch to the base/src/cas/generic/casPVI.cc file, then run make in the base/src/cas directory and rebuild all server applications.
The above function does not work properly when applied to an R3.14.9 IOC. Apply this patch to the src/ca/convert.cpp file to fix and rebuild base and the IOC application. CA Clients are not affected.
Jeff Hill reports the following:
During testing of R3.14.9 I see a bug showing up only in optimized builds on Linux using g++ 3.2.3 that I don't see with other compilers. This bug appears to be related to failure of this particular compiler to follow the strict alias rules specified in the standard when optimizing the byte swapping templates installed for R3.14.9.
- Problems
- Red hat Linux g++ 3.2.3 when -O3 is specified
- No problems
- mingw g++ 3.4.2 -O3
- Tornado 2.02 g++ -O2
- Microsoft C++ 2005 full optimization builds
This experimental vxWorks target architecture doesn't work; at iocInit() a number of the IOC tasks get suspended because they are not created with the VX_ALTIVEC_TASK flag set. A patch to fix this is now available.
Builds on RTEMS currently always link against the librtemsNfs library, even if you follow the instructions to disable that, which causes a linker error message like this:
/opt/rtems/lib/gcc/powerpc-rtems/4.0.2/../../../../powerpc-rtems/ bin/ld: cannot find -lrtemsNfsrtem
The solution is to edit the configure/os/CONFIG.Common.RTEMS file and remove -lrtemsNfs from the setting for OP_SYS_LDLIBS.
macLib fails to suppress all warnings when its FLAG_SUPPRESS_WARNINGS flag is set. Ben Franksen posted a patch for this problem.
It is not possible to build this version of base on HP-UX due to C++ issues which appear to be bugs in the HP-UX compiler.
When shutting down an IOC on a recent version of GNU/Linux (one that includes the NPTL threading library) various messages may appear, such as:
FATAL: exception not rethrown
epicsThread: Unknown C++ exception in thread "CAC-UDP" at ...terminate called after throwing an instance of ''
These errors are caused by the implementation of the pthread_cancel() mechanism in NPTL, which uses the C++ exception mechanism without providing any means to distinguish the cancel exception to regular C++ exception handlers. It is possible that they might also occur when a CA client application exits (or closes its connection to the CA library).
RTEMS builds will fail (unable to find the iocsh.h include file) unless the build for some other architecture has completed first (or at least got as far as installing the iocsh.h file). The simple workaround for this is to build for your host architecture (probably linux-x86) first. If that's not acceptable, apply this patch to the base/src/Makefile which will fix it.