2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Autosave called epicsMessageQueueSend with opMsgQueue==NULL |
From: | Henrique Almeida <[email protected]> |
To: | "Mooney, Tim M." <[email protected]> |
Cc: | EPICS Core-Talk <[email protected]> |
Date: | Thu, 28 Jan 2016 11:43:00 -0200 |
Just create the queue before starting the thread. That would be the usual pattern.
Em 27/01/2016 19:06, "Mooney, Tim M." <[email protected]> escreveu:Hi Henrique,
Thanks for this. It looks like fdbrestore() is using the message queue before the save_restore task has created it. request_manual_restore() should defend itself against this, but that wouldn't solve the problem of allowing code to call it before it can be called successfully. I should fix this so any code that starts the save_restore task waits until the task is fully functional before returning.
A workaround for now would be to call epicsThreadSleep(1.) between create_triggered_set() (which starts the save_restore task if it's not already started) and fdbrestore().
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab
From: [email protected] [[email protected]] on behalf of Henrique Almeida [[email protected]]
Sent: Wednesday, January 27, 2016 2:18 PM
To: EPICS Core-Talk
Subject: Autosave called epicsMessageQueueSend with opMsgQueue==NULL
Hello, I'm testing an IOC that uses autosave-5-6-1 from synApps 5.8 and I'm seeing a large amount of crashes during IOC boot. Spreading debug messages through EPICS code showed that autosave was calling the function epicsMessageQueueSend() with a null message queue object, for example:
(...)iocRun: All initialization complete
makeAutosaveFileFromDbInfo("/usr/local/epics/apps/config/SOL1/autosave/parker_positions1.req", "autosaveFields_pass0")dbpf SOL1:PARKER1:m1.SSET 1DBR_SHORT: 1 0x1create_triggered_set("parker_positions1.req", SOL1:PARKER1:autosave.VAL, "")fdbrestore("parker_positions1.sav")save_restore:fdbrestore:entry../save_restore.c:request_manual_restore:2678 Called epicsMessageQueueSend with opMsgQueue=NULLpmg=NULLsave_restore:806Falha de segmentação (imagem do núcleo gravada)
Core dump backtrace shows the same problem:
(gdb) bt#0 0x001e454f in mySend (pmsg=0x0, message=0xbfb95e2c, size=500, timeout=-1)at ../../../src/libCom/osi/os/default/osdMessageQueue.cpp:161#1 0x00768cd0 in request_manual_restore (filename=0x836ea3b "parker_positions1.sav",file_type=1, macrostring=0x0, callbackFunction=0x7663c0 <defaultCallback>, puserPvt=0x0)at ../save_restore.c:2680#2 0x00768e5b in fdbrestore (filename=0x836ea3b "parker_positions1.sav")at ../save_restore.c:2639#3 0x00768e8f in fdbrestore_CallFunc (args=0x83080c0) at ../save_restore.c:3566#4 0x001cfcb1 in iocshBody (pathname=<value optimized out>, commandLine=0x0, macros=0x0)at ../../../src/libCom/iocsh/iocsh.cpp:813#5 0x001d0475 in iocsh (pathname=0xbfb96729 "./parker_st1.cmd")at ../../../src/libCom/iocsh/iocsh.cpp:881#6 0x0804e33d in main (argc=2, argv=0xbfb96264) at ../motorPXIMain.cpp:17
Can anybody confirm this problem ? Here is the relevant st.cmd snippet:
set_requestfile_path("${MOTORHYPPIE_AUTOSAVE}", "")set_savefile_path("${MOTORHYPPIE_AUTOSAVE}", "")set_pass0_restoreFile("parker_positions1.sav")save_restoreSet_NumSeqFiles(0)save_restoreSet_DatedBackupFiles(0)
pxiCreateSM("motor","COM3PARKER1Motor1")
motorHyppieSetup(10, 1)
motorHyppieConfig(0,"COM3PARKER1Motor1")
dbLoadTemplate ("/usr/local/epics/apps/config/${EPICS_HOSTNAME}/parker_motor1.substitutions")
cd ${TOP}/iocBoot/${IOC}iocInit
makeAutosaveFileFromDbInfo("${MOTORHYPPIE_AUTOSAVE}/parker_positions1.req", "autosaveFields_pass0")
dbpf SOL1:PARKER1:m1.SSET 1
create_triggered_set("parker_positions1.req", SOL1:PARKER1:autosave.VAL, "")fdbrestore("parker_positions1.sav")
dbpf SOL1:PARKER1:m1.SUSE 1