RE: memory leak after unloading of ca.lib

["Hill, Jeff" <johill@lanl.gov>]

Hi Carsten,

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.

Jeff

> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-
> bounces@aps.anl.gov] On Behalf Of Carsten Winkler
> Sent: Thursday, February 23, 2017 1:50 AM
> To: tech-talk@aps.anl.gov
> 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