Xcode 7 позволяет использовать средство очистки адреса для поиска проблем с памятью в C / C ++.
https://github.com/google/sanitizers/wiki/AddressSanitizer
При включении sanitizer адреса проходит флаг компиляции и компоновщика -fsanitize=address
а также определяет _LIBCPP_HAS_NO_ASAN
,
При сборке моей библиотеки из командной строки и выполнении тестов на очищенной сборке без определения _LIBCPP_HAS_NO_ASAN
Я вижу неповторяющиеся проблемы доступа к памяти, о которых сообщалось адресным дезинфицирующим средством. определяющий _LIBCPP_HAS_NO_ASAN
Как и Xcode, избавляется от проблем с дезинфицирующим средством, но мне любопытно, зачем это нужно делать.
Почему я должен определить _LIBCPP_HAS_NO_ASAN
с AppleClang7, чтобы избежать проблем с доступом к памяти в libcxx?
Из обсуждения с Шоном Макбрайдом (который не работает в StackOverflow) обнаружены известные проблемы с ложными ошибками памяти за пределами границ при смешивании инструментированного и неинструментированного кода:
От Анны Закс http://lists.apple.com/archives/xcode-users/2016/Jan/msg00077.html:
«Как правило, не нужно перестраивать какой-либо код, который связан с очищенным кодом».
«Однако в проверке переполнения контейнера в C ++ есть один угловой случай, который может не всегда выполняться. В частности, если контейнеры libc ++ переходят от инструментального (перестроенного с помощью ASan) к неинструментированному коду, Address Sanitizer может сообщить о ложных срабатываниях переполнения контейнера. ( Представьте себе две библиотеки, каждая из которых использует один и тот же std :: vector, только одна из них оснащена инструментами. Push_back из неинструментированного модуля не пометит память для вновь добавленного элемента как действительную. Доступ к элементу из инструментированного кода вызовет ложный положительный отзыв.)
Я надеюсь, что этот вопрос поможет кому-то еще, так как эта проблема заняла значительное количество моего времени. Асан великолепен, но эту информацию было трудно найти.
Других решений пока нет …