This could be triggered if dbCaRemoveLink() is called on a link for
which there is an outstanding dbCaPutCallback().
Normally a dbCaPutCallback() callback routine is passed the associated
userPvt pointer as an argument, but in the event that dbCaRemoveLink()
gets used on the same link between the put and its completion callback,
the callback routine was being called with the link pointer as the
argument instead.
For all the existing Asyn Soft Channel device supports this is not a
problem as they all pass the link pointer as their userPvt argument, but
that won't necessarily always be the case.
Also updated the comments describing the process of removing links.
Issue diagnosed and reported by Ambroz Bizjak.
The dbContextReadNotifyCacheAllocator allocator clears
its cache of free buffers on an array size change.
But doesn't consider buffer already in use, which
will later be free'd. Such buffers were being
returned to the cache, then reused in allocations
for which they are too short.
Track the size of buffers which are in use.
Only return buffers with the present length
to the cache. Others are free'd immediately.
The yyerror() routine gets called twice in some cases.
Don't print the yytext or input file location the second
time through -- yytext has already been freed, and the
user doesn't need to see the location twice.
Fixes lp:1422803
A dbCa link does a ca_get with type DBR_CTRL_DOUBLE
to populate its list of attribute values immediately
after connecting. If the target is a DBF_*LINK field
it used to return an error, preventing the link from
properly connecting. This change makes dbGetField()
return a single NAN value instead of rejecting the
request.
Fixes: lp:545358
Windows has signed characters, but if you pass a negative
value (i.e. a character with value >= 0x80) into the debug
version of its isprint() runtime library function it asserts.
