санитайзеров ошибки которых можно поймать try-catch блоком? Я хочу например аттрибутом на try-catch блоке обозначить тип санитайзера и потом словить ошибку в catch-блоке
[[sanitizer(address)]]
try {
someBuggyFunction();
} catch(AddressSanitizerError err){
log(err);
someCleanup();
}
И С++ компилятор должен санитайзить только тот код которых находится внутри только этого try-блока (и всех вызываемых из него функций, но не всего бинарника)
По идее можно вынести этот код в отдельную либу и скомпилить с санитайзером
Нет. Санитайзеры не обязаны юзать С++ исключения
есть такая фича Conditional Compilation with __has_feature(address_sanitizer) In some cases one may need to execute different code depending on whether AddressSanitizer is enabled. __has_feature can be used for this purpose.
Зачем это собственно надо - идея заключается в том что есть например бэкенд-фреймворк который оттестирован, без UB и т.д и есть всякие джуниор С++ разработчики которые будут писать бизнес-логику (зачастую без тестов) под этот фреймворк и у которых может довольно часто втречаться UB. И для того чтобы ошибка из-за UB в коде при обработке конкретного API-запроса не валила весь процесс с бэкендом то хочется завернуть обработку запросов вот таким try-catch блоком с санитайзингом но только того кода бизнес-логики которого будут писать джуниор-разработчики Подобное можно сделать и сейчас если вынести весь код бизнес-логики в отдельный бинарник (в котором код будет скомпилирован с включенным санитайзингом) и дальше бэкенд-фреймворк на каждый API запрос запускать этот бинарник в отдельном процессе операционной системы и дальше ловить ошибку санитайзеров стандартными средствами но это очевидно будет достаточно неэффективное решение
Conditional Compilation with __has_feature(address_sanitizer)
что бы код модифицировать по минимуму и проверить конкретную фичу
что бы код модифицировать по минимуму, и проверить конкретную фичу в естественных условиях
Нет никакой гарантии, что после отловленного и предотвращённого UB программа останется в валидном состоянии.
Гарантии нет если код бизнес-логики может свободно модифицировать какие-то общие структуры фреймворка. Но если построить такую архитектуру которая будет изолировать код бизнес-логики (например все временные данные в рамках обработки запроса бизнес-логики будут аллоцироваться в арена-буффере который будет очищаться с каждым запросом ну и также в случае ошибок санитайзинга в этом catch-блоке) то я думаю мы можно достичь неких гарантий что программа останется в валидном состоянии
Ну попробуй ловить сигналы, которыми санитайзер обычно прибивает процесс после срабатывания
как я понимаю с тем как работает асан его нельзя отключить для секции кода
ОП под локальностью понимает не отключение санитайзера для части кода, а восстановление после обнаружения UB
После того как санитайзер упал продолжать исполнение так себе идея. Не понятно что там сломалось в памяти
А что там может сломаться? По идее санитайзеры просто добавляют рантайм проверки и останавливают всю программу если они не сработали А дальше можно попробовать мысленно представить что будет если вместо остановки будет просто выброс исключения (с соотвествующим вызовом деструкторов и выходом наверх по калл-стеку пока не дойдем до catch-блока) - программа находится в валидном состоянии потому что до UB дело не дошло.
Ага, например проезд по памяти который покораптил пол строки, а потом все упало, когда он обратился к памяти за ее концом
санитайзер может сработать в местах, которые в остальное время считаются за "не бросает исключений", прерывание выполнения которых нарушит инварианты и гарантии один Великий Электрон знает где после такого в лучшем случае ваше волшебное исключение долетит до выхода из noexcept функции и сделает terminate, а в худшем приложение продолжит работать с диагнозом шизофрения и на основе битых данных что-то где-то делать (самый шик такое в приложении рулящем финансами устроить)
Слушай, я не очень понимаю что-то в санитайзерах, но они же просто индексируют доступную память (вставляют проверки) и выбрасывают ошибки, когда происходит работа с памятью, которую они не проиндексировали как доступную. Ты говоришь про кейсы где невалидный код что-то натыкал в переменной выше скоупом, потом по идее человека выше, кинул исключение и теперь мы работаем с рандомным говном в этой переменной?
Разве нельзя было бы на этапе компиляции с санитайзером проверить изменил ли он переменные выше скоупом, чтобы выбрасывать просто разные исключения. Ведь если он не изменил состояние переменных, которые ещё будут использоваться, то всё хорошо.
Ну и фантазия у тебя, может тебе лучше книги писать, по типу Филипа Дика?
Обсуждают сегодня