21–30 of 31 posts
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.
Good idea to add screenshots.
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.
With allocscope, you do get a callstack for the allocations which leak, though.
I really like the picture at the top, was that the work of stable diffusion?
Earlier quoted context omitted.
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?
> can't strace trace brk() calls? Absolutely. > what is the easiest way to trace all allocations (brk() and mmap) but nothing else? strace -e mmap "$command" I don't think anything modern still uses the program break but one should know brk and sbrk exist. To see deallocations, add munmap to the filter. Note that these represent operating system allocations: programs usually request huge chunks and then manage that m…
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).
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…
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.
Depends on what you mean by "real time". My method of crawling the stack impacts execution speed of the app you are tracing. I intended to do future work to minimize that impact. With allocscope, you do get a callstack for the allocations which leak, though.
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 bar…
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.
Assuming you're running linux, there are some ebpf programs that can accomplish this already, no breakpoints needed.