[Users] memory leak in Carpet?

[ian.hinder at aei.mpg.de]

> On 2 Aug 2018, at 18:55, Miguel Zilhão <miguel.zilhao.nogueira at tecnico.ulisboa.pt> wrote:
> 
> yes, sorry. here are the labels from the tcmalloc file:
> 
> 3:generic_current_allocated_bytes
> 4:generic_heap_size
> 5:tcmalloc_pageheap_free_bytes
> 6:tcmalloc_pageheap_unmapped_bytes
> 
> column 5 (tcmalloc_pageheap_free_bytes) is not visible in the plot since it's flat zero.

Hi Miguel,

It is very hard to see what is going on, because I am having to look in two different plots, with different plot ranges, and a second email with the column number definitions.

Please can you help me to help you by organising the information a bit more clearly?

It would be good to see a single plot showing all of the data, with a legend that shows what each line is.  I assume that $6 in carpet-memory_procs is gridfunctions, but please check that and include the information in the plot.  Also, please set the plot y axis range to start at zero; it's hard to see what's going on because the two plots have different ranges, and very confusing that one of them is not zero.

From what I can tell at the moment, the new gridfunction data takes less memory than the old after the regridding, but the rss grows dramatically.  The allocated memory also grows dramatically, suggesting a memory leak, but not enough to account for the growth in rss.  It's possible that something other than regridding is responsible.  Do you have any HDF5 output enabled that might coincide with iteration 2048?  HDF5 might be allocating buffers on first output that are then not freed because they will be used again later.  Can you disable all output and see what happens?

-- 
Ian Hinder
https://ianhinder.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20180802/00f69550/attachment.html