Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Thu, 6 Nov 2003 15:45:35 -0600

Folks,

This is a followup to a message I posted on Monday.

Marty Kraimer, Andrew Johnson and I have found that there is a serious
problem with dbCA on the PowerPC architecture under EPICS 3.14.4.

The following configurations are known to fail:

- Tornado 2.0.2
- MVME2700 (vxWorks-ppc604) and MVME2100 (vxWorks-ppc603)
- gcc cross-compilers running on Solaris (standard distribution from
WRS) and on Linux (Dave Thompson's package)
- EPICS 3.14.4 (and presumably all earlier versions of EPICS 3.14).

The problem can be triggered by building the example application in
EPICS base, and then adding and loading the following single-record
database:
#####
record(stringout,"$(P)testStringOut") {
    field(VAL, "test")
    field(OUT,"$(P)testStringOut.PACT CA MS")
}
#####

This record just tries to write the string "test" to its own PACT field,
which is illegal since that is a no-write field.

Here's what happens when that record executes:
********************************
dbpf "epics:testStringOut.PROC","1"
value = -1 = 0xffffffff = ipAddrToAsciiEnginePrivate type_info node +
0xf84d4b27
filename="../dbTest.c" line number=345
dbPutField error
filename="../recGbl.c" line number=70
Attempt to modify noMod field PV: epics:testStringOut.PACT error
detected in routine: dbPut

dbCaLink: A call to "assert
((epicsMutexLock((pca->lock))==epicsMutexLockOK))" failed in ..../dbCa.c
at 757
Current time MON NOV 03 2003 13:39:05.523551896.
EPICS Release EPICS R3.14.4 $R3-14-4$ $2003/09/23 21:35:11$.
Please E-mail this message and the output from "tt (0x1b05828)"
to the author or to [email protected]

iocVxPPC604> filename="../../../src/libCom/taskwd/taskwd.c" line
number=170
task 0x1b05828 suspended
********************************

Note that the dbCaLink task dies.  This can be a very serious, but
rather subtle problem, since CA links local to an IOC are typically not
heavily used.  Thus, if one is not looking at the vxWorks console log,
it might go undetected for some time.  One problem for us is that the
save_restore task uses dbCA, and thus it stops running.  Lots of PVs
like motor positions did not get properly saved when this happened.

The problem will be triggered any time a non-zero return happens for a
dbCa link.  We initially saw the problem when the "special" function in
a record support module returned -1, because something was wrong with a
put operation.

The problem appears to be with C++ exception handling.  The stack is
getting corrupted.  Either the compiler has a problem, or there is a
problem with library interfaces.

Jeff Hill is working on the problem.

I just wanted to give everyone a heads-up on the current status.

Cheers,
Mark Rivers

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System