Live data from Hacker News

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

github.com

1–10 of 31 posts

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

#2
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).

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

#3
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.

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

#7
post #5

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

Sorry if this is a dumb question, but can't strace trace brk() calls?

And as kind of a follow up what is the easiest way to trace all allocations (brk() and mmap) but nothing else?

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

#9
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

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

#10

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

Bytehound author here.

Just from a cursory look at the README:

> allocscope-trace attaches to another process as a debugger. By using breakpoints on memory allocation functions such as malloc it tracks allocations made by that process.

Looks like it's using breakpoints so I'd expect it to be orders of magnitude slower. And looking at the source code it's also using `libunwind`, so even if it wasn't using breakpoints it'd still be at least another order of magnitude slower since Bytehound has a custom unwinder that's specially optimized for this purpose.

One advantage it has is that it can be attached to an already running process; Bytehound can't do that. (I have ideas how I could do that, and it should be technically doable by dynamically injecting Bytehound's .so into the target process' address space, but so far I haven't needed it so I did not implement it)

Post reply on HN