[Carpet] memory leak while running with carpet

[Erik Schnetter]

The Fortran 90 standard allows the compiler to not automatically  
deallocated allocatable arrays in Fortran routines.  The Fortran 95  
compilers changed this.  Some code may assume Fortran 95 semantics  
while your Pathscale compiler may insist on being a true Fortran 90  
compiler.  I don't know the Pathscale compiler, but the PGI compiler  
is such a thing.

-erik

On Jul 16, 2007, at 09:09:11, Yosef Zlochower wrote:

> Hi,
>
>   I believe I tracked the problem down to the  compiler.  I don't  
> see any
> evidence of the memory leak while using the Intel version 10.0  
> compilers,
> but do see the problem when using the pathscale version 3.0 compiler.
> I found that the the pathscale compiler produced the memory leak both
> with aggressive optimizations
>  -O3 -OPT:Ofast -fno-math-errno -ffast-math
> and with the less aggressive
>  -O2
>
> Has anyone else seen problems with memory leaks when using the psc  
> compiler
> on a similar system (AMD X86_64 procs with HTX Infiniband  
> interconnect)?
>
> Yosef
>
> Erik Schnetter wrote:
>> Hi Yosef,
>>
>> we found that the HDF5 library allocates some memory for internal
>> purposes, and continues to hold on to it, probably buffering
>> something.  This is much worse for 1.6.x than for 1.8.x.  You could
>> give 1.8.x a try.
>>
>> Christian Ott found a misbehaviour of the GNU libc which is triggered
>> by CarpetIOASCII (and probably also CarpetIOScalar and
>> CarpetIOBasic.)  Can you try running without them (or without
>> outputting anything with them) to see whether this helps?
>>
>> Apart from this a memory leak is difficult to track down.  It  
>> could be
>> anywhere -- Cactus, Carpet, your code, or it could be some  
>> interaction
>> between them.  There are no "relevant sections" of a parameter file;
>> there can only be such section if you know already where the memory
>> leak occurs.
>>
>> Can you try to remove thorns from your thorn list, trying to make the
>> memory leak go away?  After that it is necessary to watch the
>> simulation, probably in a debugger, and catch it increasing its  
>> memory
>> usage.  If you can point me to a routine we can go on from there.
>>
>> I'm afraid that your section of a parameter file doesn't ring any
>> bell.  Your parameter settings look pretty normal, and I don't see
>> such a drastic problem.
>>
>> -erik
>>
>> On Jul 10, 2007, at 03:54:45, Yosef Zlochower wrote:
>>
>>> Hi,
>>>
>>>   I forgot to mention that the memory leak is quite significant. The
>>> memory load tends
>>>  to double after a few hours of runtime.
>>>
>>> Yosef
>>>
>>> Yosef Zlochower wrote:
>>>> Hi
>>>>
>>>>  I am trying to locate the source of a memory leak in my code. I am
>>>> using
>>>> stable (version 3) version of carpet and I noticed that the memory
>>>> usage
>>>> continuously increases with time. If  I  checkpoint and restart,  
>>>> then
>>>> the memory usage goes back to its original size, but then increases
>>>> with time.
>>>>
>>>> I attached the relevant sections of the par file. Any suggestion on
>>>> how I can
>>>> track down the source of this leak. I am running the code on a  
>>>> cluster
>>>> consisting
>>>> of dual core AMD X86_64 procs with HTX Infiniband interconnect  
>>>> and the
>>>> pathscale compiler.
>>>>
>>>> Thanks
>>>>
>>>> Yosef
>>>> ------------------------------------------------------------------- 
>>>> -----
>>>>
>
> _______________________________________________
> developers mailing list
> developers at lists.carpetcode.org
> http://lists.carpetcode.org/listinfo/developers
>


-- 
Erik Schnetter <schnetter at cct.lsu.edu>

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/developers/attachments/20070716/81556425/attachment.pgp