Experimental Physics and
Industrial Control System

"Hill, Jeff" <[email protected]> · Thu, 2 Mar 2017 22:22:27 +0000

Andrew,

Considering this further, on OS with sharable libraries (i.e. windows and or linux) the ca repeater is spawned not as a thread but as an independent process, and so it's probably not involved. There _are_ some autonomous threads spawned by libCom such as the error logging thread, and therefore as in the past, perhaps only libCom would need to remain resident. In contrast, the CA client library should be shutting down its auxiliary threads if the ca context is explicitly destroyed before the CA DLL is unloaded.

And certainly some other issue could be going on which might require some quality time with the MS debugger. For example, one could imagine that the std C library atexit rundown would need to occur, for code residing in the DLL, when the DLL was unloaded. Perhaps some CA DLL atexit code is clashing with the EPICS exit facility which is orchestrated from libCom. As I recall, someone changed the std C orchestrated atexit stubs in the CA DLL to be orchestrated instead by epics exit at some point in the past.

Jeff

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Andrew Johnson
> Sent: Monday, February 27, 2017 4:37 PM
> To: [email protected]
> Subject: Re: memory leak after unloading of ca.lib
> 
> 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