Hi there,
thank you for all response. It can be summarized as follows:
#1 libCom has the errlog thread that is never stopped.
#2 libCa registers a function pointer using epicsAtExit and if it will
fail if if libca is unloaded.
#3 There are also a number of one-time allocations which aren't cleaned up.
#4 It has something to do with the ca repeater process
#5 It has something to do with LabVIEW and it's memory management
#6 Ca context destroy doesn't clean up components in libCom and other
dependent libraries
#7 Question whether libCom will be unloaded
#8 Cleaning up with epicsExit()
My questions/answers to this points:
#1 Where/when exactly this thread is started? How can I terminate it?
#2 When will the function epicsAtExit called in my demo?
Do you think, this function pointer leaves bad memory sections in my
case?
#3 That's what I'm looking for. Do I have any chance to resolve it?
#4 No, the caRepater is not involved. When I run my test app there is no
caRepeater process running.
#5 No, LabVIEW was the trigger only to investigate the issue. But every
program with plugin interface will have the same problem. The most
simple example is my test case.
#6 How can I do the necessary clean up?
#7 In Windows I see that Com.dll won't be unloaded. I guess it's the
same in Linux. How can I detect loaded libs at runtime?
Will unloading of libCom solve the issue?
#8 The function epicsExit() ends with exit(status); and will terminate
calling program too. That is what I try to prevent.
Phew, it seems to be quite complicated. Hope we find a solution together.
Best regards
Carsten
Am 23.02.2017 um 23:51 schrieb Michael Davidsaver:
> On 02/23/2017 05:26 PM, Hill, Jeff wrote:
>>>> The CA client library _is_ cleaning up all of its allocations if
>>> ca_context_destroy is explicitly called, but this is of course not universal for
>>> components in libCom and or EPICS base.
>>>
>>> https://github.com/epics-base/epics-base/blob/3.14/src/ca/access.cpp#L139
>>>
>>> https://github.com/epics-base/epics-
>>> base/blob/3.14/src/ca/ca_client_context.cpp#L56
>> It does appear, from my perspective, to be cleaning up there but I could have another look if that’s not the case.
> It is cleaning up with epicsExit(), not ca_context_destroy().
>
________________________________
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
- Replies:
- Re: memory leak after unloading of ca.lib Michael Davidsaver
- References:
- memory leak after unloading of ca.lib Carsten Winkler
- Re: memory leak after unloading of ca.lib Michael Davidsaver
- Re: memory leak after unloading of ca.lib Ben Franksen
- RE: memory leak after unloading of ca.lib Hill, Jeff
- Re: memory leak after unloading of ca.lib Michael Davidsaver
- RE: memory leak after unloading of ca.lib Hill, Jeff
- Re: memory leak after unloading of ca.lib Michael Davidsaver
- Navigate by Date:
- Prev:
RE: Question about PV operation that defined in ai.template. Mark Rivers
- Next:
Re: memory leak after unloading of ca.lib Michael Davidsaver
- 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>
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: memory leak after unloading of ca.lib Michael Davidsaver
- Next:
Re: memory leak after unloading of ca.lib Michael Davidsaver
- 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>
2018
2019
2020
2021
2022
2023
2024
|