Experimental Physics and
Industrial Control System

Jeff Hill <[email protected]> · Mon, 23 Sep 1996 15:04:48 -0600

William Lupton wrote:

> 
>   The problem is a fatal "bad client read io id from server" message 
> (from the CA client library) which then, I believe, unconditionally 
> calls abort(). 

This bug was fixed last fall in CVS tag epics_R3_12_1_3 (created on
1995/09/29). I suspect that the application code is linking against a
version of the the CA client library created prior to this date. 

The solution is to relink the client against a more recent version of EPICS.

Sorry about the any grief that this has caused.

Jeff

PS: Here are some of the original bug reports on this problem:

> Chris,
> 
> > 
> > A CA client application is giving the message:
> > "Message: Channel Access Internal Failure"
> > "Severity: Fatal"
> > "Context bad client read io id from server"
> > 
> > Unfortunately, this seems to be an intermitent failure
> > that happens a few times a day while the client is polling
> > some PVs.
> > 
> > If you have any additional info. on this message, I'd like
> > to know.
> 
> After a quick look in the source I see that this problem exists 
> in 3.12.1.1 and is fixed in 3.12.2.1. The problem was discovered
> by Fred Vong at APS and was related to a race condition where
> the CA client lib receives a message for a particular resource 
> (a channel or a monitor) shortly after that resource was deleted.

> Fred,
> 
> > The first one is that the channel acccess still calls my connection event handler
> > and access right handler after I call the ca_clear_event() and ca_clear_channel().
> >
> > The above unexpected callbacks only happen when you call ca_clear_event() and
> > ca_clear_channel() during the IOC reboot but before the channel access prints
> > out the lost connection message.
> 
> This is a bug. It will show up under the following circumstances:
> 
> o The client has a valid connection to an IOC
> o The client deletes a channel on that IOC
> o The IOC disconnects prior to returning its delete confirm message 
> 
> > Calling ca_change_connection_event() with a NULL handler solves the first problem but
> > calling ca_replace_access_right_event() with a NUll handler results as a segmentation
> > fault.
> 
> This is also a bug. 
> 
> It will occur only if you attempt to set the access rights handler to NULL. 
> 
> 
> > 
> > The second one is that the channel access calls my event handler with args.dbr = NULL.
> > This happens during I am doing a lot of connections, disconnections, ca_add_event()
> > and ca_get_callback().  The debugger shows args.dbr = NULL.
> > 
> 
> This isnt a bug.
> 
> This would occur during normal operation if the status in struct event_handler_args 
> wasnt ECA_NORMAL (indicating the the requested operation failed in the IOC) or if 
> there isnt any data returned (ie put call back).
> 
> An example of an operation failing in the IOC would be attempting to
> read an ai PV that is in INVALID alarm because the hardware isnt present.
> 
> You would also be called back with a NULL dbr pointer and status equal to
> ECA_DISCONN if a get call back was outstanding and the IOC disconnected.
> 
> There are omissions in the document in this area and I have eliminated
> them (but not updated the web yet).
> 
> Code changes for all of the above will show up in EPICS 3.12.2. 
> 
> Thanks for your assistance tracking down these problems.
> 

-- 

______________________________________________________________________
Jeffrey O. Hill			Internet	[email protected]
LANL MS H820			Voice		505 665 1831
Los Alamos, NM 87545 USA 	FAX		505 665 5107

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System