Re: Patch: Enhancement to asTrapWrite?

[Andrew Johnson <anj@aps.anl.gov>]

Hi Jeff,

Jeff Hill wrote:
> +    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  ....

Actually the message is never queued; the registered callbacks are 
executed directly by the asTrapWriteBefore() and asTrapWriteAfter() 
routines that rsrv calls on either side of db_put_field().

The Access Security chapter of the AppDevGuide describes the current 
API, but doesn't make it very clear that the before and after data can 
be obtained from the serverSpecific pointer which on the IOC points to a 
 dbAddr that can be used to access the field to be modified, both 
before and after it is changed.  [Eric - were you aware of this and 
rejected it for some reason?]

The modified version should be fine as long as the user copies the data 
out of the message before the second callback returns (which I would add 
to the description in the AppDevGuide if we accept the patch).  I'm more 
concerned about whether we should extend the message like this, given 
that it's probably not necessary.

- 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