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: Crash on IOC exit |
From: | "Mooney, Tim M." <[email protected]> |
To: | "Johnson, Andrew N." <[email protected]>, "[email protected]" <[email protected]> |
Date: | Mon, 5 Mar 2018 18:41:57 +0000 |
Thanks,
I added this code and committed recDynLink.c to gitHub.
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 Andrew Johnson <[email protected]>
Sent: Monday, March 5, 2018 11:31:27 AM To: [email protected] Subject: Re: Crash on IOC exit Hi Mark,
On 03/04/2018 01:40 PM, Mark Rivers wrote: > My IOC application is crashing on exit with an access violation. > > spinnakerApp: caught exception 0xC0000005 "Access violation"... > > Base 7.0.1 (master) > Windows 7 > Visual Studio 2015, debug, static > > I have appended the debugger screen shot. It tells me that pParm->pName > is a bad pointer. > > When I run the application without the debug build I see this on > application exit: > > Thread recDynInp (000000000D7F4DB0) suspended > Thread recDynOut (000000000D7F4E10) suspended > > This leads me to suspect that the crash is happening when it attempts to > get the name of the recDynInp or recDynOut task? This looks like a bug in the sscan module. We have added quite a lot of proper shut-down code to other parts of Base in recent years. If threads from other modules don't register an appropriate epicsAtExit() routine and stop trying to call the IOC APIs while shutdown is occurring, they can end up trying to access memory that has been freed. In this case it seems that in sscanApp/src/recDynLink.c both recDynLink threads register themselves with the task watchdog, but don't remove themselves from it before they exit. That would agree with the error messages you're seeing from the debug build, which almost certainly come from taskwd. In the stack-trace you posted the taskwd subsystem is trying to use a hanging pointer presumably to one of those threads. If you add the line taskwdRemove(0); immediately before the closing brace of both the recDynLinkInp() and recDynLinkOut() functions this should remove those threads from the watchdog and stop it from trying to display those "suspended" messages. HTH, - Andrew -- Arguing for surveillance because you have nothing to hide is no different than making the claim, "I don't care about freedom of speech because I have nothing to say." -- Edward Snowdon |