EPICS Home

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  <20172018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: memory leak after unloading of ca.lib
From: Xiaoqiang Wang <[email protected]>
To: Epics <[email protected]>
Date: Wed, 29 Mar 2017 21:33:48 +0200
Hi,

Just for reference’s sake, I have wrongly attributed the hangup to unload ca.dll/Com.dll.
In my case, the hangup comes from a bug in Python cffi library and gets fixed.[1]

Best
Xiaoqiang

[1] https://bitbucket.org/cffi/cffi/commits/9fe2a9e060945f60c32a22d41d70c5a026fb146d

> On 23 Mar 2017, at 21:38, Wang Xiaoqiang (PSI) <[email protected]> wrote:
> 
> 
> Hi Carsten, Michael,
> 
> Sorry to revive this old thread. But I am facing similar problem to solve. This time not with Labview but with Python cffi.
> 
> From the discussion I understood that the workaround is not to unload libca/libCom.
> On Linux, I have used the RTLD_NODELETE flag and that solve the problem.(https://linux.die.net/man/3/dlopen)
> 
> On 64bit Windows, I made a boring wrapper dll. https://github.com/CaChannel/caffi/tree/master/wrapper
> The wrapper loads ca.dll with LoadLibrary call and calls the loaded symbols for the CA API. And at the end it does not call FreeLibrary, so that the loaded symbols live until the program ends. Do you guys see any problem with this approach?
> 
> 
> Best
> Xiaoqiang
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Carsten Winkler
> Sent: Donnerstag, 23. Februar 2017 09:50
> To: [email protected]
> Subject: memory leak after unloading of ca.lib
> 
> Hi there,
> 
> when your project (e.g. LabVIEW) uses dynamic loading and unloading of channel access classes your main class will sometimes (at 64 bit nearly
> always) crush with a segmentation fault. The reason seems to be missing
> free() and delete functions in EPICS Base 3.14.12.6 (I'm sure this applies also to other EPICS Base versions).
> 
> I wrote a tiny test case to check it and it would be great to get any advise to solve the issue.
> 
> Best regards
> Carsten
> 
> 
> ________________________________
> 
> Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
> 
> Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.
> 
> Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta Koch-Unterseher
> Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking
> 
> Sitz Berlin, AG Charlottenburg, 89 HRB 5583
> 
> Postadresse:
> Hahn-Meitner-Platz 1
> D-14109 Berlin
> 
> http://www.helmholtz-berlin.de


References:
memory leak after unloading of ca.lib Carsten Winkler
RE: memory leak after unloading of ca.lib Wang Xiaoqiang (PSI)

Navigate by Date:
Prev: Re: INP string length Michael Davidsaver
Next: 答复: Question about PV name by using pcaspy lzf neu
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: memory leak after unloading of ca.lib Carsten Winkler
Next: RE: Why we want Lua on the IOC Hill, Jeff
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024