Experimental Physics and
Industrial Control System

"Chris Timossi" <[email protected]> · Thu, 1 Aug 2002 11:55:54 -0700

I've written a CA client that calls ca_array_get_callback in a loop to get a
few PVs. I've been testing the client's ability to reconnect to the server
by rebooting the IOC while the client is running.

What I find is that if the client loops too fast (< 100ms) and I reboot the
server that the client will report 'no callback' for 5 seconds (as it
should) but then get a run-time error with the message:

	a call to "assert (status == S_bucket_success)" failed in
\epics\base\src\ca\access.c line 1490 (version R3.13.5)

It seems that once ca recognizes that the connection is lost, an attempt is
made to remove the caIOBlock from a list but the removal fails. The stack
trace looks like this:

caIOBlockListFree(ELLLIST * 0x00885210, channel_in_use * 0x0088bfe8, int 1,
int 192) line 1508
cacDisconnectChannel(channel_in_use * 0x0088bfe8) line 1533 + 26 bytes
cac_close_ioc(ioc_in_use * 0x00e90198) line 1462 + 9 bytes
checkConnWatchdogs(unsigned int 1) line 142 + 9 bytes
cac_mux_io(timeval * 0x0012fd5c, unsigned int 1) line 2115 + 9 bytes
cac_block_for_io_completion(timeval * 0x0012fd5c) line 240 + 11 bytes
ca_pend(double 0.00050000002374873, int 0) line 2912 + 9 bytes

/*
 * caIOBlockFree()
 */
void caIOBlockFree(miu pIOBlock)
{
	int	status;

	LOCK;
	status = bucketRemoveItemUnsignedId(
			ca_static->ca_pFastBucket,
			&pIOBlock->id);
	assert (status == S_bucket_success);
	pIOBlock->id = ~0U; /* this id always invalid */
	freeListFree(ca_static->ca_ioBlockFreeListPVT, pIOBlock);
	UNLOCK;
}

Could it be that there's a potential race between checkConnWatchdogs and
ca_array_get_callback over a list of caIOBlocks? I notice that both routines
are bracketed with LOCK/UNLOCK (which I guess arent implemented for most
OSs).

I've only seen this happen with Windows.

Chris Timossi
LBNL

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System