Недавно, в моем проекте возникла проблема. Суть ее заключалась в не стабильных крэшах приложения, которые было очень трудно воспроизвести и редко повторялись, но тем не менее они присутстовали, чем сильно раздражали. Главая из версий, объясняющая их была до банальности проста – не коректная работа с памятью. На поиски освобожденных / не освобожденных объектов было потрачено не один день. Было найдено и справленно несколько других багов связанных с памятью, но это не привело к ожидаемому результату.
Буквально недавно, я узнал, что в Xcode 3.2 есть возможность статического анализа кода. Статический анализ – это анализ выполняемый над версией кода, с целью выявления мест содержащих ошибки. Встроеный в Xcode 3.2 анализатор, основан на консольном анализаторе clang. Если вы щасливый обладатель OS X Snow Leopard и Xcode 3.2, то советую вам прочитать статью из эпловской документации:
иначе читаем далее.Для начала нам предстоит установить анализтор clang. Для этого мы должны скачать архив checker-0.223.tar.bz2 с сайта:
и распаковать его, скажем, на рабочий стол. В итоге, на вашем рабочем столе, у вас окажется папка checker-0.223. Теперь переместим папку checker-0.223 в дирректорию /usr/bin. Запустите Терминал, перейдите на Рабочий стол и выполните команду:
sudo mv checker-0.223 /usr/bin/
Теперь перейдите в папку /usr/bin/ и создайте символьные ссылки на статический анализатор и просмотрщик результатов:
sudo ln -s checker-0.223/scan-build scan-build
sudo ln -s checker-0.223/scan-view scan-view
На этом установка анализатора завершена. Перейдем непосредственно к настройке проэкта. Настраивать особо много не прийдется, только Code sign и Base SDK. Для настройки Code sign, зайдите в настройки таргета, на вкладку Build, перейдите в секцию Code signing и для ключа Any iPhone Device выберете Don't Code Sign:
Теперь зайдите в настройки проэкта, на вкладку General и выберите iPhone Simulator 2.1 для Base SDK for All Configurations.
На этом настройка проекта окончена, можно преступать непосредственно к билду и анализу, кода.
При установке Xcod'а, по умолчанию установливается замечательная консольная утилита xcodebuild. Она позволяет собирать ваш проект из под консоли. Именно связка xcodebuild + scan-build, даст нам возможность найти баги в нашем коде.
Создадим новый Window Based проект с названием TestProject и добавим в метод applicationDidFinishLaunching код:
NSString *testString;
NSString *testString2;
testString2 = [testString copy];
Сразу предупрежу вас, что код заведомо содержит ошибки. Они созданы с целью показать возможности статического анализатора.
Теперь сохраним проект, запустим консоль и перейдем в папку проекта. Остается только выполнить статический анализ. Очень хорошо, перед каждым анализом очистить проект. Для этого вызовете команду:
scan-build xcodebuild -configuration Debug clean
ну и после ее выполнения, запустите сам статический анализатор:
scan-build -k -V xcodebuild -configuration Debug
В результате, после билда и анализа у вас в консоль напишется что то типа того:
И по идеи, должен запуститься браузер с отчетом о найденых багах. Но к сожалению не всегда это происходит. Если у вас такой случай, то не беспокойтесь, просто перейдите по пути, вывевшемся в консоли и запустите вручную файл отчета:
cd /var/folders/qE/qEWzPoglGVWOVJJ2d-amzU+++TI/-Tmp-/scan-build-2009-10-05-1
open index.html
В результате у вас загрузится браузер, в котором будет html отчет отображающий результат анализа:
Сам отчет разделен на 3 части:
- информация о билде (пользователь, дата путь);
- количество найденных багов, разбитые на категории;
- список файлов, в которых найдены баги.
Для удобства вы можете выбрать определенный тип ошибок, убрав или проставив галочки. Наибольший же интерес для нас представляет раздел Reports, в котором, как сказанно выше, отображается список файлов в которых найдены баги. Нажав на ссылку View Report, вы можете просмотреть подробный отчет по определенной ошибке в файле. В подробном отчете отображается линия в которой найдено уязвимое место и примерное описание что не так. Вам остается хорошенько проанализировать код, ведь анализатор не искуственный интеллект, и если уязвимость подтверждается, исправить ее.
Если честно, для меня остается загадкой, по какому приницпу определяются файлы в которых присутствуют ошибки. Так как бывали такие места, в которых явно были “опсные” места, а анализатор не помечал их. Надеюсь в ближайшем будущем я разберусь в этом и подправлю статью. Хоть анализатор нашел в проекте несколько критических утечек, но все равно приходится быть внимательным. Чего и вам желаю.
