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: Carsten Winkler <carsten.winkler@helmholtz-berlin.de>
To: Michael Davidsaver <mdavidsaver@gmail.com>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
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  <2017
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
ANJ, 01 Mar 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·