Comment 4 for bug 541221

Confirmed bug still present in R3.14.9:

#5 0x00c04850 in epicsAssert (pFile=0x944f3f "../dbCa.c", line=656,
    pExp=0x944f71 "pca->pgetNative", pAuthorName=0xc15973 "the author")
    at ../../../src/libCom/osi/os/default/osdAssert.c:71
        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
$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',
    gotFirstConnection = 1 '\001',
    connect = 0,
    monitor = 0,
    userPvt = 0x0,
    putType = 0,
    putCallback = 0,
    putUserPvt = 0x0,
    plinkPutCallback = 0x0,
    gotAttributes = 1 '\001',
    getAttributes = 0,
    getAttributesPvt = 0x0,
    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,
            lastGetdbrType = 0},
        ...,
    },
    type = 11
}

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.