On 4/25/19 1:21 PM, Iain Marcuson wrote:
> I don't need to use the database as such, but how do I wait until iocInit() has run?
initHookRegister() in initHooks.h
One example of many.
https://github.com/mdavidsaver/pscdrv/blob/fe17f67adc7ee1462d76bf03a4229bf5c921e4bf/coreApp/src/pscbase.cpp#L268
> Iain.
>
> -----Original Message-----
> From: Michael Davidsaver <[email protected]>
> Sent: Thursday, April 25, 2019 4:17 PM
> To: Iain Marcuson <[email protected]>
> Cc: [email protected]
> Subject: Re: A call to 'assert(dbLockIsInitialized)' by thread '_main_'
>
> dbGetField() can't be used prior to iocInit().
> If you have to touch records at this point (which seems unusual for a driver) then dbPutString() is the way to go.
>
>
> On 4/25/19 1:14 PM, Iain Marcuson via Tech-talk wrote:
>> I am writing a driver for a camera we have developed. Part of the scheme involves monitoring a PV at about 20 Hz to check for a trigger. I get this message on trying to read the PV. I tried an initial read in the main thread to capture the problem before too much else was started.
>>
>>
>>
>> A call to 'assert(dbLockIsInitialized)'
>>
>> by thread '_main_' failed in ../../../src/ioc/db/dbLock.c line 246.
>>
>> Dumping a stack trace of thread '_main_':
>>
>> [ 0x7fcec9b5334b]:
>> /home/iainm/local/opt/epics/base/lib/linux-x86_64/libCom.so.3.15.4(epi
>> csStackTrace+0x4b)
>>
>> [ 0x7fcec9b4c8ca]:
>> /home/iainm/local/opt/epics/base/lib/linux-x86_64/libCom.so.3.15.4(epi
>> csAssert+0x4a)
>>
>> [ 0x7fcec9d9cdb2]:
>> /home/iainm/local/opt/epics/base/lib/linux-x86_64/libdbCore.so.3.15.4(
>> dbScanLock+0x1f2)
>>
>> [ 0x7fcec9d9f45c]:
>> /home/iainm/local/opt/epics/base/lib/linux-x86_64/libdbCore.so.3.15.4(
>> dbGetField+0x2c)
>>
>> [ 0x40dbef]:
>> ../../bin/linux-x86_64/HPE3631Atest(_ZN10SpectroCCDC2EPKcS1_imiiS1_+0x
>> 74f)
>>
>> [ 0x40de82]:
>> ../../bin/linux-x86_64/HPE3631Atest(_ZL14configCallFuncPK11iocshArgBuf
>> +0x62)
>>
>> [ 0x7fcec9b3efb0]:
>> /home/iainm/local/opt/epics/base/lib/linux-x86_64/libCom.so.3.15.4(ioc
>> shBody+0xae0)
>>
>> [ 0x40c3b2]: ../../bin/linux-x86_64/HPE3631Atest(main+0x12)
>>
>> [ 0x7fcec9249f45]:
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)
>>
>> [ 0x40c3fd]: ../../bin/linux-x86_64/HPE3631Atest(_start+0x29)
>>
>> EPICS Release EPICS R3.15.4 $Date: Fri 2016-05-27 08:54:04 +0200$.
>>
>> Local time is 2019-04-25 13:01:39.451503845 PDT
>>
>> Please E-mail this message to the author or to [email protected]
>> <mailto:[email protected]>
>>
>>
>>
>> The record in question is
>>
>>
>>
>> record(longin, "$(P)$(R)Cmd_GET_HW_TRIG_DR0")
>>
>> {
>>
>> }
>>
>>
>>
>> And the reading code is
>>
>>
>>
>> pv_opts = 0;
>>
>> pv_nreq = 1;
>>
>> dbGetField(&hw_trigger_addr_, DBR_LONG, &pv_val,
>>
>> &pv_opts, &pv_nreq, NULL);
>>
>>
>>
>> pv_val, pv_opts, and pv_nreq are of type long, as in other parts of the code that work.
>>
>>
>>
>> What might I do or look up to solve this problem?
>>
>>
>>
>> Thank you,
>>
>>
>>
>> Iain.
>>
>
- References:
- A call to 'assert(dbLockIsInitialized)' by thread '_main_' Iain Marcuson via Tech-talk
- Re: A call to 'assert(dbLockIsInitialized)' by thread '_main_' Michael Davidsaver via Tech-talk
- RE: A call to 'assert(dbLockIsInitialized)' by thread '_main_' Iain Marcuson via Tech-talk
- Navigate by Date:
- Prev:
RE: A call to 'assert(dbLockIsInitialized)' by thread '_main_' Iain Marcuson via Tech-talk
- Next:
Re: database or new record for blocking setpoint/readback process control Lang, Keenan C. via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: A call to 'assert(dbLockIsInitialized)' by thread '_main_' Iain Marcuson via Tech-talk
- Next:
RE: A call to 'assert(dbLockIsInitialized)' by thread '_main_' [SOLVED] Iain Marcuson via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
|