Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 27 Feb 2017 17:37:04 -0600

On 02/23/2017 12:17 PM, Hill, Jeff wrote:
> As I recall there were issues occurring when the CA client code
> spawning the ca repeater, and other standalone autonomous threads,
> within a lab view process. If the lab view block explicitly, and
> abruptly, unloaded the ca client DLL, this could ultimately cause the
> still running ca repeater thread to crash due to its continuing to
> execute code no-longer mapped into virtual memory. The legacy fix was
> to cause the reference count on the DLL to be artificially
> incremented so that the DLL would stay in memory. Perhaps something
> changed in EPICS base, with the management API for windows 64 bit
> DLLs, or alternatively with newer versions of lab view which has
> eliminated this protection.

The base/src/libCom/osi/os/WIN32/osdThread.c file contains a DllMain()
routine for Com.dll which is what Jeff is describing above, although I
don't know how it works or if we may have somehow disabled it in more
recent releases. Those with more Windows knowledge than I are welcome to
comment and suggest if this can be made to fix Carsten's problem. Jeff's
original commit message when he added this routine in 2005 was:

> make certain that com.dll remains resident for its daemon threads even if the
> user explicitly uloads it (from a labView DLL)

Could the solution just be to give ca.dll its own copy of this routine?

- 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System