Experimental Physics and
Industrial Control System

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

 

 

 

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.