[fratajcz]

ASAN is great for development, but a less cynical reason for not enabling it at an OS level is that it would add quite a bit of overhead: "Typical slowdown introduced by AddressSanitizer is 2x." (clang docs)

There is also some memory overhead:

* AddressSanitizer uses more real memory than a native run. Exact overhead depends on the allocations sizes. The smaller the allocations you make the bigger the overhead is.

* AddressSanitizer uses more stack memory. We have seen up to 3x increase.

* On 64-bit platforms AddressSanitizer maps (but not reserves) 16+ Terabytes of virtual address space. This means that tools like ulimit may not work as usually expected. Static linking of executables is not supported.

It's not as bad as something like valgrind, but it's certainly not something you'd want enabled on every single process.

[jart]

2x is very reasonable compared to alternatives like full emulation and electric fencing. It is production worthy. I use -fsanitize-address with static linking all the time. You just have to roll your own runtime to do that. All it entails is a little glue to veneer mmap() and malloc() so it calls memset() to poison (ADDR>>3)+0x7fff8000 appropriately.