How to debug long-lived D program memory usage?

[Alex]

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.


Curious, what are these programs?

You might have hook in to the GC and just write out stats, I 
believe there is a stats collector somewhere though.

I did this by replacing new and monitored and calculated the 
allocations. This didn't help for any GC issues but at least made 
sure all my allocations were correct.

What you could do is something similar to this and just output 
stuff to a text file(that is written every so often).

If they programs are not too large you could used named 
allocations that could then be graphed individually(or use the 
file locations, __FILE__, etc).

Search and replace all new's and allocs with your custom ones and 
override the GC's.

Should give you a good idea of what's going on.