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: Carsten Winkler <[email protected]>
To: Michael Davidsaver <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Tue, 28 Feb 2017 16:22:18 +0100
Hi there,

the trick worked to use dlopen() instead of .so dependencies. THANK YOU!
But as in Linux 32-bit you have to delay the unload of the stub library
(in my case 5 seconds).

I think it can work as workaround but is not the real fix for the issue.

If you check libca.so and libCom.so at Linux 64-bit you will see
following log:

standard@standard-VirtualBox:~$ valgrind --leak-check=full
--show-leak-kinds=all
/usr/local/epics/base-3.14.12.6/lib/linux-x86_64/libca.so
==4880== Memcheck, a memory error detector
==4880== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4880== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==4880== Command: /usr/local/epics/base-3.14.12.6/lib/linux-x86_64/libca.so
==4880==
==4880== Jump to the invalid address stated on the next line
==4880==    at 0x23166: ???
==4880==    by 0x12C9AF: assertIdenticalMutex (epicsGuard.h:81)
==4880==    by 0x12C9AF: cac::flush(epicsGuard<epicsMutex>&) [clone
.part.63] (cac.cpp:1208)
==4880==  Address 0x23166 is not stack'd, malloc'd or (recently) free'd
==4880==
==4880==
==4880== Process terminating with default action of signal 11 (SIGSEGV)
==4880==  Bad permissions for mapped region at address 0x23166
==4880==    at 0x23166: ???
==4880==    by 0x12C9AF: assertIdenticalMutex (epicsGuard.h:81)
==4880==    by 0x12C9AF: cac::flush(epicsGuard<epicsMutex>&) [clone
.part.63] (cac.cpp:1208)
==4880==
==4880== HEAP SUMMARY:
==4880==     in use at exit: 0 bytes in 0 blocks
==4880==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4880==
==4880== All heap blocks were freed -- no leaks are possible
==4880==
==4880== For counts of detected and suppressed errors, rerun with: -v
==4880== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

standard@standard-VirtualBox:~$ valgrind --leak-check=full
--show-leak-kinds=all
/usr/local/epics/base-3.14.12.6/lib/linux-x86_64/libCom.so
==4885== Memcheck, a memory error detector
==4885== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4885== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==4885== Command: /usr/local/epics/base-3.14.12.6/lib/linux-x86_64/libCom.so
==4885==
==4885== Jump to the invalid address stated on the next line
==4885==    at 0x1D556: ???
==4885==    by 0x12706A: epicsMutex::lock() [clone .part.2]
(epicsMutex.cpp:249)
==4885==  Address 0x1d556 is not stack'd, malloc'd or (recently) free'd
==4885==
==4885==
==4885== Process terminating with default action of signal 11 (SIGSEGV)
==4885==  Bad permissions for mapped region at address 0x1D556
==4885==    at 0x1D556: ???
==4885==    by 0x12706A: epicsMutex::lock() [clone .part.2]
(epicsMutex.cpp:249)
==4885==
==4885== HEAP SUMMARY:
==4885==     in use at exit: 0 bytes in 0 blocks
==4885==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4885==
==4885== All heap blocks were freed -- no leaks are possible
==4885==
==4885== For counts of detected and suppressed errors, rerun with: -v
==4885== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Best reagards
Carsten

Am 24.02.2017 um 21:33 schrieb Michael Davidsaver:
> On 02/24/2017 12:46 PM, Carsten Winkler (HZB) wrote:
>> Hi Michael,
>>
>> thanks for your help.
>>
>> I wrote a stub library first, before I got the memory issues. It worked
>> very well (since 2010) in Windows at 32-bit and 64-bit. In Linux 32-bit
>> I could avoid the problem with delayed unloading the stub lib. Now I
>> want to support Linux 64-bit too. But the delay trick doesn't work in
>> that environment. That's the full story. You see, I have an old project
>> that's running into problems under special conditions.
>> Do you have any other advice for me?
> Other the totally unhelpful suggestion not to use labview ;) you could
> have your stub library use dlopen() instead of .so dependencies.
>
>
>> 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


________________________________

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 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
Re: 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 Carsten Winkler (HZB)
Re: memory leak after unloading of ca.lib Michael Davidsaver

Navigate by Date:
Prev: PCASpy 0.6.3 Wang Xiaoqiang (PSI)
Next: RE: RE: RE: Re: IOC Connecting Problem Pilkyu Jung
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 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  <20172018  2019  2020  2021  2022  2023  2024