Как отлавливать ошибки, возникающие в AddressSanitizer в библиотеках C ++, доступных через расширение Python
У меня есть модуль Python, который использует внешнюю библиотеку C ++, используя сборку расширения C ++ с distutils. Когда я компилирую библиотеку C ++ с помощью средства очистки адреса, опция -fsanitize GCC, я получаю ошибку segfault при запуске модульных тестов. Первоначально я думал, что это потому, что я использовал разные параметры компилятора для двух двоичных файлов, расширения Python C ++ и библиотеки, но теперь я все больше и больше убежден, что это потому, что средство очистки адресов нашло ошибку в библиотеке и вызвало Сег Вина, как объяснено Вот.
Это также подтверждается тем фактом, что если я скомпилирую библиотеку C ++ без очистителя адресов, все будет работать нормально.
Когда я запускаю модульные тесты, программа выводит очень мало информации:
./run_unit_tests
Segmentation fault (core dumped)
Даже глядя на дамп ядра, я смог найти только трассировку стека, указывающую на библиотеку C ++, но без упоминания о дезинфицирующем устройстве адресов.
Я попытался использовать ASAN_OPTIONS, чтобы перенаправить вывод дезинфицирующего средства в файл, но дезинфицирующее средство, по-видимому, не выбирает параметры:
ASAN_OPTIONS=help=1 ./run_unit_tests
Segmentation fault (core dumped)
Какую стратегию я должен здесь использовать, чтобы подтвердить, что ошибка сегмента произошла от дезинфицирующего средства и, возможно, обнаружить, что это за ошибка?
Решение
Сначала несколько уточнений:
это связано с тем, что средство очистки адреса обнаружило ошибку в библиотеке и вызвало ошибку сегмента
Когда Асан обнаруживает ошибку, он всегда выдает дружественное сообщение об ошибке. Segfault означает, что
- в какой-то момент либо прибор не работал
- или (гораздо менее вероятно) инструментальный код случайно вызвал некоторую уже существующую критическую ошибку
Это также подтверждается тем фактом, что если я скомпилирую библиотеку C ++ с неопределенным поведением sanitizer, все будет работать нормально
UBSan является много проще, чем ASan, так что в целом вы не можете действительно поделиться выводами о них.
Я попытался использовать ASAN_OPTIONS, чтобы перенаправить вывод дезинфицирующего средства в файл, но дезинфицирующее средство, по-видимому, не выбирает параметры:
Дело в том, что help=1 fails говорит нам о том, что дезинфицированное приложение было повреждено при раннем запуске, прежде чем Asan смог разобрать ASAN_OPTIONS и реагировать соответственно. Это обычно происходит, когда есть некоторая основная проблема в том, как был включен Асан.
Я думаю, что ты скучаешь LD_PRELOAD=path/to/libasan.so настройка среды, которая требуется при применении Asan к одному DSO вместо основного приложения (как в случае с очищенными плагинами C / C ++ для интерпретаторов, проверьте Asan FAQ).
Если это не помогает, я предлагаю предоставить больше информации (например, версия GCC, символизированный стек в точке segv).
Другие решения
Других решений пока нет …