[Carpet] memory leak while running with carpet

[Yosef Zlochower]

Thanks Erik,

  I'll test the code by removing those thorns and checking the memory load.


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
>>> ------------------------------------------------------------------------ 
>>>
>>>