Is there a convenient way to get a heap profile in Rust? I'd expect it shouldn't be too hard. I'm used to using pprof with tcmalloc, jemalloc is based on tcmalloc, and Rust uses jemalloc by default.<p>pprof heap profiles make this kind of thing easy to debug. It draws a call graph using graphviz. Boxes are scaled according the total byte size, so if there's a large leak you can pull up the graph and the giant box all but says "you idiot, the problem is right here".
> At this point I was tired so I fell asleep. This isn't done, of course -- we still need to chase the Rust program to figure out why that allocation never gets freed. But it's a start!<p>The type of .boxed() would probably help. I would expect a .boxed to return a Box<_> (e.g. Vec::into_boxed_slice(v) returns a Box<[_]>) which would get RAII-deallocated. So either .boxed() returns a raw pointer for some reason, or it properly returns a Box but leaks internally.
Does Valgrind work with Rust binaries? If yes, then this would make everything much easier. You just compile in debug mode and say `valgrind --leak-check=full`, and it will give you stacktraces to the allocations that were not freed.
Neat! Hadn't come across this tool before but it let me track down a PulseAudio crash that's been bugging me for months. Turns out that it was unloading a shared library whilst executing code from that shared library, which meant that the inevitable crash happened in code that was no longer loaded, and that was why I couldn't get a meaningful backtrace at the time of the crash. The call to dlclose() right before the crash was a huge hint; knowing that was the last library function called made it easy to set a breakpoint and catch it in the act.<p>Thanks for the tip!
I'd be curious to see the full source code. A memory leak from an owned pointer should be impossible unless you're using `unsafe` somewhere in your code or in a library you're pulling in.