| 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 2025 | 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 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: Would it be recommended to delete an asynPortDriver object when the IOC exits? |
| From: | Mark Rivers <[email protected]> |
| To: | "'Heesterman, Peter J'" <[email protected]>, "EPICS Tech-Talk ([email protected])" <[email protected]> |
| Date: | Thu, 14 Jan 2016 19:42:57 +0000 |
|
This is a tricky problem because EPICS is doing a callback with a pointer to the asynPortDriver object, but that object has now been deleted. The destructor does not have access to that pointer that EPICS base is using, so it cannot set
it to NULL to signify that the object has been deleted. I think the solution is to add an epicsAtExit function in the base class which sets a “rebooting” flag. If that flag is true then pPvt must be assumed to be invalid and all routines that use pPvt should immediately return before accessing
pPvt. Mark From: [email protected] [mailto:[email protected]]
On Behalf Of Heesterman, Peter J Hi, I invoke epicsAtExit to provide call-back notification that the IOC is exiting (in response to the user typing ‘exit’). It seems to me good practice to delete the C++ IOC object, before the application exits, so as to prevent resource leaks. (Rather than relying on the operating system to de-allocate.) However, in my application , this results in unhandled access violation(s) after the object has been deleted (at least, in a debug build). This occurs in the readInt32 call-back function, where it attempts to call pPvt->lock(). I believe this is caused by continued (threaded) scan polling of the record, after the object referenced has been destroyed. It’s not a major problem. Many thanks, Peter. |