Closed ee7 closed 4 months ago
Due to the false positives when we scan the stack during GC, abort_on_error isn't a good one to set.
By the way, 80% of what this sanitizer does isn't going to be useful without us doing extra work.
This is because we almost never use malloc(); we mmap our own heaps in, with guard pages both before and after the allocation. So it won't have enough context to detect out-of-bounds writes but still within our heap, and anything that goes outside the bounds of the heap we are already going to be catching via mprotect.
It's still modestly useful for globals, and possibly useful for things passed on the stack.
The correct thing to do is to go through the effort of manually poisoning / unpoisoning the space between allocations via their API. I'm sure the next time I've got a clear memory scribble I'll end up doing the work; it isn't too hard.
I think the recent work on custom checking obviates anything else w/ ASAN unless shown otherwise, considering this done.
Not a high priority ticket - just for tracking/visibility.
E.g. as a diff to the workflow:
I tend to use approximately those options to make ASan more aggressive than the default, and to make UBSan output more useful.