Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 1 Aug 2002 15:14:13 -0600

Hi Chris,

I took a quick look at R3.13.7 and I don't see an obvious cause of this.
Are you using multiple threads to call CA? If so, beware that on all OS
other than vxWorks the R3.13 CA client library is _not_ thread safe. In
contrast, the R3.14 ca client library is thread safe on all OS that
EPICS runs on.

If you are not calling CA from multiple threads then, if it's reasonable
to set up, please E-mail a small program that reproduces this.
Otherwise, I might find this by staring at the source code, but this can
be time consuming, and if you have a small code that could be an
efficient tool to resolve this problem.

Jeff

> -----Original Message-----
> From: Chris Timossi [mailto:[email protected]]
> Sent: Thursday, August 01, 2002 12:56 PM
> To: [email protected]
> Subject: ca_array_get_callback LOCK
> 
> 
> 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