Hacker News Reader

Comment by saagarjha | Hacker News Reader

Do note that "custom allocator" can often just be "take what malloc gives you and carve it up yourself" rather than "interpose malloc"; there's usually no need to drop the system allocator completely. This lets you experiment with your own custom pools or arenas without having to go all in and make something general-purpose that works for every object in your program.

> Over the years, I’ve wasted many hours debugging memory issues. With just a hash table and a set of linked lists, you can track the history of all your allocations. That makes it pretty easy to track down use after free errors, double free errors, and memory leaks. Using guard pages around your allocations, you can detect overflows.

No, just use address sanitizer–it's meant for this. Odds are your custom allocator might have a few bugs in itself and they will make you life more annoying if you're trying to use it for only this.

View on HN

I just went from "wtf is an address sanitizer" to "what's the difference between this and valgrind" to an ASAN acolyte in about 1 minute.

http://btorpey.github.io/blog/2014/03/27/using-clangs-addres...

Article mentions JVM noise, but my actual experience is with python noise. Good riddance; this is going into my CI test suite today.

Yes! The sanitizers have been a huge game changer for me.

Having used sanitizers to find a couple C++ bugs I am convinced that Rust is a better solution to that problem. I would never have found the C++ issues without extra tooling, so just use Rust, learn the rules and let the compiler make you write correct code. To clarify, yes ASAN is awesome but using a language where you don't need it is better.

How does rust help fix bugs in a C++ code base?

When there's no more C++ there will be no bugs in the C++ code base ;-)

j/k, though I've fixed memory bugs, overflow, use after free, etc. written by people much smarter than me. without static analyzers, valgrind, and afl its possible that some would still exist nearly a decade later.

Any custom allocator in Rust will use a lot of unsafe code.

I would hope all the analysis Rust does can inform the choice of built-in allocator so you dont need to roll your own.

Also, any custom C++ allocator is going to contain a bunch of unsafe code too.

I'm not sure what you mean by "all the analysis"; by default Rust just calls malloc.

It's true that a C++ custom allocator will have lots of "unsafe" code, but this is really where C++ shines. The tooling is more complete, the aliasing rules are better documented and understood, the language fights you less, the stdlib has explicit support, it is easier to control the codegen. Rust cannot bring its strengths to bear on this sort of problem.

> No, just use address sanitizer

In fairness, the next sentence in the post is:

> Techniques like this can be a nice complement to external tools like Valgrind or AddressSanitizer.

I feel like it just mentioned Valgrind when I read it.

You can do interesting things by replacing malloc, like this compacting allocator:

https://github.com/plasma-umass/Mesh

Reply on news.ycombinator.com