Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 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
<== Date ==> <== Thread ==>

Subject: RE: memory leak after unloading of ca.lib
From: "Hill, Jeff" <johill@lanl.gov>
To: Andrew Johnson <anj@aps.anl.gov>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: 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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
> On Behalf Of Andrew Johnson
> Sent: Monday, February 27, 2017 4:37 PM
> To: tech-talk@aps.anl.gov
> 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


References:
memory leak after unloading of ca.lib Carsten Winkler
RE: memory leak after unloading of ca.lib Hill, Jeff
Re: memory leak after unloading of ca.lib Andrew Johnson

Navigate by Date:
Prev: Hamamatsu sCMOS detectors andrew.wilson
Next: Problem with EPICS palak shimpee
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
Navigate by Thread:
Prev: Re: memory leak after unloading of ca.lib Andrew Johnson
Next: RE: memory leak after unloading of ca.lib Wang Xiaoqiang (PSI)
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
ANJ, 23 Mar 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·