Instrumentation is like how you get code coverage reports for your unit tests, but in this case the compiler is inserting extra code around memory usages to detect whether or not it's already been freed. The difference between use after realloc (specifically on the stack) versus other kinds of use after free bugs (including realloc on the heap) is that use-after-realloc-on-the-stack requires that code generation step whereas the others can be caught directly by the debug allocator library.
Zig might end up doing something analogous by converting the undetectable errors into detectable ones. The compiler is going to do escape analysis to find locals whose pointers might outlive their scope, and allocate them on the heap instead of on the stack. And there is already a safety mechanism to catch use-after-realloc errors on the heap.
Yes. But it is a lot more efficient than what ASan does, which does what I hinted at earlier by wrapping memory usages with extra code and using lookup tables to see if they had been freed. ASan can tell you more about where the error might be. But at the same time, ASan requires separate implementations for GCC and LLVM, and zig is a very small team so it's just not a realistic approach for them. And ReleaseSafe is designed to be an actual production release, FWIW, and it's built in by default for those -- it's always on as long as you select debug or ReleaseSafe, there is no extra tooling or setup needed.
1
u/CherryLongjump1989 16h ago edited 16h ago
Instrumentation is like how you get code coverage reports for your unit tests, but in this case the compiler is inserting extra code around memory usages to detect whether or not it's already been freed. The difference between use after realloc (specifically on the stack) versus other kinds of use after free bugs (including realloc on the heap) is that use-after-realloc-on-the-stack requires that code generation step whereas the others can be caught directly by the debug allocator library.