'assert (pca->pgetNative)' failed in ../dbCa.c
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
EPICS Base | Status tracked in 7.0 | |||||
3.14 |
Fix Released
|
Undecided
|
Unassigned | |||
3.15 |
Fix Released
|
Undecided
|
Unassigned | |||
3.16 |
Fix Released
|
Undecided
|
Unassigned | |||
7.0 |
Fix Released
|
High
|
Andrew Johnson |
Bug Description
From Michael Abbott [michael atsign araneidae.co.uk]
A call to "assert (pca->pgetNative)" failed in ../dbCa.c line 625.
EPICS Release EPICS R3.14.6 $R3-14-6$ $2004/05/28 19:27:47$.
Current time Fri Nov 19 2004 08:59:06.536066000.
Please E-mail this message to the author or to <email address hidden>
Calling epicsThreadSusp
Steps to reproduce:
Actually, it was pretty simple: the IOC that crashed was running one
record, a sub array (with data type FLOAT) pointing to an array on another
IOC (with data type USHORT). I restarted the second IOC, changing the
data type of the array to FLOAT: *!bang!*
Version: R3.14.9
Original Mantis Bug: mantis-164
http://
Changed in epics-base: | |
assignee: | nobody → Andrew Johnson (anj) |
From Emma Shepherd:
I have come across a problem on an R3.14.8.2 IOC that is affecting channel access links - some records are in LINK ERROR and others have CP links that fail to update. When we started investigating we found that the CAC-TCP-recv task was in SUSPEND+I state, and the following messages had been printed to the console:
BL18I-MO- IOC-01. diamond. ac.uk:1 Wed Aug 15 16:37:26 2007 CAC-TCP-recv: A call to "assert (pca->pgetNative)" failed in ../dbCa.c at 629 IOC-01. diamond. ac.uk:1 Wed Aug 15 16:37:26 2007 Current time WED AUG 15 2007 15:37:23.708349950. IOC-01. diamond. ac.uk:1 Wed Aug 15 16:37:26 2007 EPICS Release EPICS R3.14.8.2 $R3-14-8-2$ $2006/01/06 15:55:13$. IOC-01. diamond. ac.uk:1 Wed Aug 15 16:37:26 2007 Please E-mail this message and the output from "tt (0x1e0ff9e0)" IOC-01. diamond. ac.uk:1 Wed Aug 15 16:37:26 2007 to the author or to <email address hidden>
BL18I-MO-
BL18I-MO-
BL18I-MO-
BL18I-MO-
Here is the task trace:
BL18I-MO-IOC-01 -> tt 0x1e0ff9e0 ateGet+ f8 : epicsThreadCall EntryPoint () EntryPoint+ 15c: 1e88b718 (1) :run(void) +990: 1e88e78c () 1e88e78c tcpiiu: :processIncomin g(epicsTime const &, callbackManager ponse(callbackM anager &, tcpiiu &, epicsTime const &, caHdrLargeArray &, char *) () ponse(callbackM anager &, tcpiiu &, epicsTime const &, caHdrLargeArray &, char *)+bc : cac ::eventRespActi on(callbackMana ger &, tcpiiu &, epicsTime const &, caHdrLargeArray const &, void *) () ction(callbackM anager &, tcpiiu &, epicsTime const &, caHdrLargeArray const &, void *)+19 4: ::completion( epicsGuard< epicsMutex> &, cacRecycle &, unsigned int, unsigned long, void const *) () ::completion( epicsGuard< epicsMutex> &, cacRecycle &, unsigned int, unsigned long, void co nst *)+84 : ::current( epicsGuard< epicsMutex> &, unsigned int, unsigned long, void const *) () ::current( epicsGuard< epicsMutex> &, unsigned int, unsigned long, void const *)+104: 1e815 434 () endSelf () endSelf+ 2c : taskSuspend () value = 0 = 0x0
231ff8 vxTaskEntry +68 : 1e8cb6e4 ()
1e8cb754 epicsThreadPriv
1e8bd048 epicsThreadCall
1e88b718 tcpRecvThread:
&)+408: cac::executeRes
1e87a588 cac::executeRes
1e875fc8 cac::eventRespA
netSubscription
1e89a364 netSubscription
oldSubscription
1e855ff4 oldSubscription
1e8156d0 dbCaGetUnits +790: epicsAssert ()
1e8c9a5c epicsAssert +154: epicsThreadSusp
1e8cb010 epicsThreadSusp
Any ideas what could have caused this?