Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 27 Sep 2007 14:17:05 -0600

Andrew,

+    pwriteMessage->message.dataType = dataType;
+    pwriteMessage->message.dataptr = dataptr;

I don’t claim to have looked at orchestration of the trap write message in complete detail, but it appears that a dangling pointer problem exists with this mod. It looks like a pointer to dbr data in rsrv's protocol buffer is sitting in the message queue, but strong potential for rsrv immediately copying in a new message overwriting what the pointer is pointing at, before the message is dispatched to the callback, exists. Also, the client could disconnect and then the protocol buffer memory is reclaimed to the free list and later given to a different client  ....

Jeff

> -----Original Message-----
> From: [email protected] [mailto:core-talk-
> [email protected]] On Behalf Of Andrew Johnson
> Sent: Thursday, September 27, 2007 11:22 AM
> To: EPICS core-talk
> Cc: Eric Berryman
> Subject: Patch: Enhancement to asTrapWrite?
> 
> I received the attached patch from Eric Berryman, which I'm posting
> here for additional comments.  The change should not break existing
> asTrapWrite plug-ins since it merely adds fields to the message
> structure that contains all of the information about the write being
> performed — the fields it adds contain the new data and metadata from
> the put.  However it does increase the size of the asTrapWriteMessage
> structure from 4 to 7 pointers.
> 
> I can see that it simplifies the use of the asTrapWrite API, but I am
> not convinced that it is strictly necessary.  The existing API does not
> provide the put data & metadata directly, but this information can be
> obtained from the record field by the 'after' call to the registered
> plug-in.  This would not be true if the put causes record processing
> which modifies the value of the field before the 'after' call, but by
> forcing users to fetch the 'after' data they also find out what the
> real effect was of that put, not just what the client tried to do (if
> you rely only on what was in the put buffer as provided by this patch
> you can't be 100% sure what value actually ended up in the field).
> 
> Comments, positive or negative?
> 
> - Andrew
> --
> When a distinguished but elderly scientist states that something is
> possible, he is almost certainly right.  When he states that something
> is impossible, he is very probably wrong.  -- Arthur C. Clarke

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System