8 ms·
In a complex C codebase, valgrind is absolutely indispensable for finding the last few bits of memory that may have leaked out because you got lazy and didn't f
by theideaofcoffee 2y ago
In a complex C codebase, valgrind is absolutely indispensable for finding the last few bits of memory that may have leaked out because you got lazy and didn't free() or maybe you wrote somewhere in memory you shouldn't have, it really is like magic sometimes. I know that more recent languages (and some not so recent, looking at you, Ada!) have a lot of this built in by default, but when you need to do these things, you know you need to and it's nice to have a handy all-in-one tool to help out. It's saved me many times from myself when I was writing network code in C and I couldn't figure out where the leaks were coming from, or a performance regression by inspecting the code alone. A quick run of valgrind had that fixed in minutes.
- flohofwoe 2y agoIME the main problem with Valgrind is that it reduces performance too much (I remember something around 10x slowdown or worse). Clang's address sanitizer OTH finds most of the same problems, but with much a smaller performance hit, which makes it also useable for things like games. Also for leak detection, some IDEs have excellent realtime debugging tools (for instance there a very nice memory debugger in Visual Studio since VS2015, and XCode has Instruments).
- theideaofcoffee 2y agoGood point, there definitely is the performance hit for the observability data it gives you, but for me, that's a fair trade for the results it gets me. I can see how working with things that have more realtime-ish constraints like games would be more greatly affected. Still, works super well for systems software, so I continue to use it.