dbpf before iocInit crashes IOC

[Dirk Zimoch]

When calling dbpf before iocInit, the IOC crashes in dbScanLock while accessing an uninitialized semaphore.

Tested with R3.14.12, R3.15.4 and R3.16.1

Here is the relevant stack trace:
#2 0x00007f1a8c020098 in epicsThreadSuspendSelf () from /usr/local/epics/base-3.14.12/lib/SL6-x86_64/libCom.so
#3 0x00007f1a8c01edeb in epicsAssert () from /usr/local/epics/base-3.14.12/lib/SL6-x86_64/libCom.so
#4 0x00007f1a8c8d6a5a in dbScanLock () from /usr/local/epics/base-3.14.12/lib/SL6-x86_64/libdbIoc.so
#5 0x00007f1a8c8d8faf in dbPutField () from /usr/local/epics/base-3.14.12/lib/SL6-x86_64/libdbIoc.so
#6 0x00007f1a8c8e883a in dbpf () from /usr/local/epics/base-3.14.12/lib/SL6-x86_64/libdbIoc.so

Either calling dbpf before iocInit should fail gracefully or dbPutField should not try to lock the database before iocInit.

[Dirk Zimoch (dirk.zimoch)]

dbgf shows the same behavior.

[mdavidsaver (mdavidsaver)]

Yup, this has always been the case. dbGetField() calls dbScanLock() which won't work until after iocInit() (specifically dbLockInitialize() ).

https://github.com/epics-base/epics-base/blob/3.14/src/db/dbLock.c#L245

I suppose that dbgf/dbpf could be made to eg. test interruptAccept and use dbGetString() vs. dbGetField().

[Andrew Johnson (anj)]

I'm putting checks into dbpf, dbgf, dbtpf, dbtpf and dbtr so they won't try to call dbAccess routines and hence try to use dbScanLock() if the addr.precord->lset field is NULL (this gets initialized when the locksets are calculated, and should work with both the old and new dbLock.c implementations.

Changes to allow dbgf or dbpf to be used before iocInit would be enhancements and are out of scope of this bug fix.