Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Tue, 20 Apr 2010 14:21:47 +0200

Hi Ben,
You are right. The link gets initialized too early. I allocate the
memory in the device support but that's already too late.
I suspect that the idea was to allow bptr to be a pointer to hardware
registers or third party buffers and thus save the time for copying the
data from hardware to bptr. The code even says:

/* init records sets the bptr to point to the data */

if((status=(*pdset->init_record)(paao))) return(status);

But that can never have worked properly with local links.
aai does the same late allocation. Writing to or reading from aai
through a db link crashes the ioc too.
Modifying the records to do the allocation is tricky. There might be
device supports out there that do allocation for bptr without checking
for not NULL. My version of the Soft Channel support does the check but
there may be others. In that case the device support and links from
other records would use different buffers.
It may be safer to move pdset->init_record to pass 0. I have not found
any other record type that does this. Can there be any problem with this
approach?
Who uses aai/aao and which device supports exist?
Dirk

Benjamin Franksen wrote:

On Tuesday 20 April 2010, Dirk Zimoch wrote:

Tim Mooney wrote:

Dirk,  I was seeing something similar (though in 3.14.11),
and "dbpr <recordname>,5" showed "DTYP: <nil>",
until I added the line
device(aao,CONSTANT,devAaoSoft,"Soft Channel")
to the .dbd file.

Hi Tim.
That is not the problem:
DTYP: Soft Channel
The ioc also crashes when the aao record is not processed! Thus DTYP
cannot be the problem.

I believe the aao record support is at fault.
The problem is that it does not allocate bptr itself but leaves this to
device support. However, when device support's init_record method is called,
it is too late. Because by then links have already been initialized, thus
cvt_db_addr has been called, which sets the field address to bptr, i.e.
NULL.
This explains why regular puts work but puts via db links lead to a crash.
If you dbpf from the ioc shell or do caput, the cvt_db_addr gets called and
since this is after device support init, bptr will contain a valid pointer
to the array.
You could verify my theory by issuing a 'caput aao1.OUT aao2'. After this,
the IOC should not crash when processing aao1. It shoudl still crash when
processing ao1, until you re-initialize thits OUT link, too.
Solution: Fix aao (and probably aai) record support to either allocate bptr
itself or else call device support's init_record during the first pass of
record support initialization.
Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System