IOC segmentation fault related to CA security
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
EPICS Base |
Fix Released
|
High
|
mdavidsaver | ||
3.14 |
Fix Released
|
High
|
mdavidsaver | ||
3.15 |
Fix Released
|
High
|
mdavidsaver | ||
3.16 |
Fix Released
|
High
|
mdavidsaver |
Bug Description
On 04/15/2016 05:27 PM, Pearson, Matthew R. wrote:
>
> Hi,
>
> I’ve had a few instances of one of my soft IOCs crashing with a segmentation fault when I shutdown another IOC that hosts a PV used as part of the CA security logic on the other crashed IOC.
>
> There is sometimes (but not always) this message printed out before the crash:
>
> dbCa:exceptionC
> nativeType DBR_invalid requestType DBR_invalid nativeCount 0 requestCount 0 noReadAccess noWriteAccess
>
> Printing the stack trace:
>
> Core was generated by `../../
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007f5321218599 in ellDelete (pList=
> 87 pNode->
> Missing separate debuginfos, use: debuginfo-install glibc-2.
> (gdb) bt
> #0 0x00007f5321218599 in ellDelete (pList=
> #1 0x00007f532217c289 in casAccessRightsCB (ascpvt=
> #2 0x00007f5321d64122 in asComputePvt (asClientPvt=
> #3 0x00007f5321d63ea0 in asComputeAsgPvt (pasg=0x1f91ee0) at ../asLibRoutine
> #4 0x00007f5321d62419 in asComputeAsg (pasg=0x1f91ee0) at ../asLibRoutine
> #5 0x00007f5321d60482 in connectCallback (arg=...) at ../asCa.c:99
> #6 0x00007f53214c1301 in oldChannelNotif
> #7 0x00007f53214abe30 in nciu::unrespons
> #8 0x00007f53214b7c38 in tcpiiu:
> #9 0x00007f532149a042 in cac::destroyIIU (this=0x7f52d00
> #10 0x00007f53214b27e3 in tcpSendThread::run (this=0x7f52d40
> #11 0x00007f532122bc51 in epicsThreadCall
> #12 0x00007f53212333ce in start_routine (arg=0x7f52d400
> #13 0x00007f53204a29d1 in start_thread () from /lib64/
> #14 0x00007f53207a08fd in clone () from /lib64/libc.so.6
>
>
> The crashed IOC has a CA access security rule that looks like:
>
> ASG(DEFAULT)
> {
> INPA("$
> RULE(1, READ)
> RULE(1, WRITE)
> {
> CALC("A=0")
> }
> RULE(1, WRITE)
> {
> UAG(epics, beamline, detector)
> HAG(beamline)
> CALC("A=1")
> }
> }
>
> where $(P):Scan:Active is hosted by the IOC that I’m shutting down.
>
> In addition there is a channel access link between the two IOCs involving a CP link.
>
> I can’t reliably reproduce it, but it’s happened a few times today as I was testing it (stopping and starting the IOC hosting $(P):Scan:Active perhaps 20 times).
>
> Anybody have ideas about this?
>
> Our base version is 3.14.12.4 running on RHEL6.
http:// www.aps. anl.gov/ epics/tech- talk/2016/ msg00692. php