Setting NAME field in DB file may break IOC
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
EPICS Base | Status tracked in 7.0 | |||||
3.14 |
Fix Released
|
Undecided
|
Unassigned | |||
3.15 |
Fix Released
|
Undecided
|
Unassigned | |||
3.16 |
Fix Released
|
Undecided
|
Unassigned | |||
7.0 |
Fix Released
|
Undecided
|
Andrew Johnson |
Bug Description
The Database runtime prevents SPC_NOMOD fields from being written to when the database is running.
However, during DB file parsing, this mechanism is not active, and such fields are set to the value from the database file.
In the case of
record(ai, "foo") {
field(NAME, "bar")
}
This leads to a situation where
> softIoc -d test-name.db
Starting iocInit
###
## EPICS R3.15.4 $$Date$$
## EPICS Base built Jun 14 2016
###
iocRun: All initialization complete
epics> dbl
bar
epics> dbpr foo
PV 'foo' not found
epics> dbpr bar
PV 'bar' not found
epics>
Channel Access also doesn't find the record.
When using an ASYN driver, we have seen IOCs segfault when the field NAME was set to a string containing invalid characters (an ampersand '&' in our case).
Should we disallow setting SPC_NOMOD fields from database files?
Should we silently ignore them? Print warnings?
Or should setting the NAME field call dbRenameRecord() instead of dbPutString()?
I can't think of any use case were modifying a SPC_NOMOD field would make sense. I think disallowing writes to these fields at database-load time would make sense.
Side-note: The Record Reference Manual says DTYP can NOT be modified (https:/ /wiki-ext. aps.anl. gov/epics/ index.php/ RRM_3-14_ dbCommon# Field_Summary_ 5) while dbCommon.dbd lists DTYP without "special( SPC_NOMOD) "? Am I missing something or is the Wiki wrong here?