Show HN: I wrote a tool in Rust for tracking all allocations in a Linux process

Neat. I had made something similar for work a while back, but as a LD_PRELOAD library that intercepted calls to malloc and friends. It would add extra space to every allocation so it could add a pointer at the end that would point into a leaf node of a call graph backtrace tree it maintained. Each node in the tree had lifetime allocated/freed block counts and bytes by code site. The cool part about it was that it barely affected the performance of the application.

It made its own socket and thread to listen on it. It would just dump a snapshot of tree to anything that connected. I also had some tooling that would let you diff two snapshots, since it was helpful to see if particular stimuli cause persistent extra allocations. While finding the largest outstanding delta between allocated and free bytes was great for finding leaks, sorting by lifetime count of blocks allocated was also fun. I remember some little puzzle game I enjoyed playing at the time would allocate and free tens of thousands of blocks as you dragged a line around for a second.

There was a tricky chicken and egg problems with LD_PRELOAD wrapping one of the allocation functions, because it was used internally by dlsym, which I was using to retrieve pointers to the proper function implementations. (calloc if I recall correctly.) I hacked around it by making my library allocate bytes out of a static char array for the calloc call that would happen while dlsym-ing for calloc. Debugging this was a nightmare, since it would break so early in the process's lifetime that GDB breakpoints weren't functioning. Tracking in a second process seems like a way simpler idea, and probably doesn't have too much of an impact on performance.

Sounds interesting but I'd very much appreciate knowing what the output any exploration capabilities look like in allocscope-view before jumping into installation, maybe add some screenshots to the readme. Poking around the code it looks like a curses-based interface.

That looks quite neat.

Though I'm currently not on a x64 linux, and since the main selling point seems to be the TUI it would be great to have a couple screenshots, or even better a gif of an asciinema recording (or whatever people use now).

Could you compare/contrast its functionality to https://github.com/KDE/heaptrack ?

Interesting approach. How is performance compared to something like https://github.com/koute/bytehound

Thanks for sharing! I built a similar tool (also in Rust) which allows tracing system and library calls, and could be used for this purpose. I wanted to expose the functionality both as a library and CLI, but for now I’ve only published documentation on using the CLI.

https://github.com/JoshMcguigan/backlight

If this project can trace memory allocation/deallocation and their call stacks in real time -- this would be super useful, because we can statistically profile which function is always allocating without proper free in a certain time frame (when the memory is supposed to be freed), because valgrind only tells you there are memory leaks but not where is the leak exactly.

I'd be curious to see how this ptrace tool performs compared with one that relies on ELF symbol interposition (a la LD_PRELOAD). Other heap profilers (heaptrack, libtcmalloc, etc) use this method. Presumably the loader resolves the symbols once at load time and there's little cost overhead to switch to the profiler code.

However, as a practical matter those solutions might omit mmap which some applications might use for anonymous allocations.

Assuming you're running linux, there are some ebpf programs that can accomplish this already, no breakpoints needed.

I really like the picture at the top, was that the work of stable diffusion?

Let me guess: it made the HN front page because Rust.

So it's like strace looking for brk()?