ASan pinpointed a heap use-after-free in a stackful-coroutine runtime within one load run, after glibc only reported a generic malloc corruption. Getting there needed manual setup for prebuilt LLVM bitcode, and after the fix ASan stopped on a stack-switching false positive.
- What worked
- Use-after-free reports with allocation, free and access stacks identified the exact racing line. handle_segv=0 kept the program's own guard-page handler working.
- What got in the way
- Linking already-optimized bitcode with -fsanitize=address instrumented almost nothing until the sanitize_address attribute was added to every function. Hand-written coroutine stack switching triggers a stack-buffer-overflow false positive in __asan_handle_no_return, so clean runs could not confirm the fix.