Here's what I think is happening: When a dbCa link reconnects with a different type or element count, the connectionCallback() routine frees the original buffer that was allocated to store the incoming data. Usually the buffer will be pca->pgetNative but it could be pca->pgetString instead. There is a comment in the above code that says "Let next dbCaGetLink and/or dbCaPutLink determine options" which seems reasonable, but it doesn't take account of the possibility that a monitor event could come in before the record next gets processed. The above assertion in the eventCallback() routine demonstrates that this is what has happened.
Confirmed bug still present in R3.14.9:
#5 0x00c04850 in epicsAssert (pFile=0x944f3f "../dbCa.c", line=656, 0xc15973 "the author") ./src/libCom/ osi/os/ default/ osdAssert. c:71
pExp=0x944f71 "pca->pgetNative", pAuthorName=
at ../../.
current = {secPastEpoch = 585681673, nsec = 843834202}
date = "Wed Jul 23 2008 12:21:13.843834202"
status = <value optimized out>
#6 0x0093ad01 in eventCallback (
arg = {
usr = 0x8528738,
chid = 0x857c430,
type = 19,
count = 10,
dbr = 0x85c7da0,
status = 1
}) at ../dbCa.c:656
pca = (caLink *) 0x8528738
plink = (DBLINK *) 0x8528400
size = 40
precord = (dbCommon *) 0x85282c0
monitor = (dbCaCallback) 0
userPvt = (void *) 0x0
(gdb) print *pca nection = 1 '\001', lback = 0x0, esPvt = 0x0,
lastGetdbr Type = 0},
$4 = {
node = {next = 0x0, previous = 0x0},
lock = 0x8528820,
plink = 0x8528400,
pvname = 0x8528838 "anjHost:array",
chid = 0x857c430,
link_action = 0,
sevr = 3,
timeStamp = {secPastEpoch = 585681666, nsec = 713450592},
dbrType = 2,
nelements = 10,
hasReadAccess = 1 '\001',
hasWriteAccess = 1 '\001',
isConnected = 1 '\001',
gotFirstCon
connect = 0,
monitor = 0,
userPvt = 0x0,
putType = 0,
putCallback = 0,
putUserPvt = 0x0,
plinkPutCal
gotAttributes = 1 '\001',
getAttributes = 0,
getAttribut
controlLimits = {0, 0},
displayLimits = {0, 0},
alarmLimits = {0, 0, 0, 0},
precision = 0,
units = "",
pgetNative = 0x0,
pgetString = 0x0,
pputNative = 0x0,
pputString = 0x0,
gotInNative = 0 '\0',
gotInString = 0 '\0',
gotOutNative = 0 '\0',
gotOutString = 0 '\0',
newOutNative = 0 '\0',
newOutString = 0 '\0',
nDisconnect = 2,
nNoWrite = 0
}
(gdb) print *plink
$5 = {
value = {
...,
pv_link = {
pvname = 0x8528490 "anjHost:array",
precord = 0x85282c0,
pvt = 0x8528738,
getCvt = 0,
pvlMask = 8,
...,
},
type = 11
}
Here's what I think is happening: When a dbCa link reconnects with a different type or element count, the connectionCallb ack() routine frees the original buffer that was allocated to store the incoming data. Usually the buffer will be pca->pgetNative but it could be pca->pgetString instead. There is a comment in the above code that says "Let next dbCaGetLink and/or dbCaPutLink determine options" which seems reasonable, but it doesn't take account of the possibility that a monitor event could come in before the record next gets processed. The above assertion in the eventCallback() routine demonstrates that this is what has happened.