Тут вышла статья от Кости Серебряного -- человек, который себе карьеру сделал на ASAN, Fuzzing и тд про GWP-ASAN. Это своеобразная модификация аллокатора, которая не включает полную мощь ASAN в проде, так как будут проблемы с оверхедом, а создаёт отдельный буффер, где страницы памяти Linux чередуются -- то, из чего можно читать и то из чего нельзя (PROT_NONE), таким образом легче словить out of bounds ошибки. При аллокациях выдаётся память из одного региона, где можно читать, при деаллокации тоже помечается PROT_NONE, а при use after free, если повезёт, и попадёт туда, куда не надо, то найдёт ошибку в C/C++ подобном коде. Тем самым случайным образом аллокации попадают в буффер и имеют шансы обнаружить ошибки уже не в тестах, а в проде. Ну, мы знаем такие техники, и вероятности не очень большие поймать при одном запуске. Прелесть такого метода в том, что оверхед минимальный, меньше 0.2%
А теперь предположим у вас есть софт, который распространяется на тысячи, миллионы людей и девайсов. Google, Apple, Meta, приложения в Google/App Store, софт Windows, игра в Steam или просто серверы и их много, и работают они долго. Так получается, что вы теперь проверяете на корректность не какой-то участок кода при запуске, а размазываете ASAN на все аллокации на тысячах и миллионах устройств.
Сотни, тысячи багов, простая имплементация и красивая история. Ни тесты, ни фаззинг не спасают от багов в проде
А теперь предположим у вас есть софт, который распространяется на тысячи, миллионы людей и девайсов. Google, Apple, Meta, приложения в Google/App Store, софт Windows, игра в Steam или просто серверы и их много, и работают они долго. Так получается, что вы теперь проверяете на корректность не какой-то участок кода при запуске, а размазываете ASAN на все аллокации на тысячах и миллионах устройств.
Сотни, тысячи багов, простая имплементация и красивая история. Ни тесты, ни фаззинг не спасают от багов в проде