It has an option to zero out allocations/deallocations. I wonder if it would be useful to randomize the memory instead. It seems like this would help surface bugs better than either zeroing it or leaving it alone?

Rather than random data, it is more typical to poison with a repeating pattern (like 0xAAAAAAAA). This is usually easy to spot in a backtrace, even with minor mutations.

The point of the allocator is security, not debugging.

Perhaps it would help even from a security perspective, though. It would make it harder to scan the heap for deallocated memory regions, for what that's worth.

The choice of CRC32 together with a secret seems odd, it seems to be relying on a security property which CRC32 doesn't have.

This looks like the kind of application that SipHash is designed for.

As long as results are different on every application run and app crashes when there's a mismatch, you don't need anything as strong as SipHash since your previous guesses don't narrow options for your future attack attempts.

Speed? CRC32 has dedicated CPU instructions on recent x64.

And size. The whole header ought to fit in 64 bits (a single cmpxchg), which rules out all of the good secure hashes.

How does scudo compare with libdislocator?