How to debug long-lived D program memory usage?

[Julian]

On Wednesday, 17 April 2019 at 16:27:02 UTC, Adam D. Ruppe wrote:
> D programs are a vital part of my home computer infrastructure. 
> I run some 60 D processes at almost any time.... and have 
> recently been running out of memory.
>
> Each individual process eats ~30-100 MB, but that times 60 = 
> trouble. They start off small, like 5 MB, and grow over weeks 
> or months, so it isn't something I can easily isolate in a 
> debugger after recompiling.
>
> I'm pretty sure this is the result of wasteful code somewhere 
> in my underlying libraries, but nothing is obviously jumping 
> out at me in the code. So I want to look at some of my existing 
> processes and see just what is responsible for this.
>
> I tried attaching to one and `call gc_stats()` in gdb... and it 
> segfaulted. Whoops.
>
>
>
>
> I am willing to recompile and run again, though I need to 
> actually use the programs, so if instrumenting makes them 
> unusable it won't really help. Is there a magic --DRT- argument 
> perhaps? Or some trick with gdb attaching to a running process 
> I don't know?
>
> What I'm hoping to do is get an idea of which line of code 
> allocates the most that isn't subsequently freed.

One thing you can try, without recompiling, is using pmap -x
on one of the bloated processes, and then dumping a large
memory region to file, and then just looking at the binary.

It might be something obvious on visual inspection.

You can dump memory with

   gdb -p $pid --eval-command 'dump binary memory file.bin 
0xfromLL 0xtoLL' -batch