Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 28 Sep 2007 17:06:46 -0500

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System