Рассмотрим основные цели, которые преследуют люди, занимающиеся этим:

Реклама

Реклама для легальных компаний, которые таким образом пытаются привлечь внимание покупателей к своим товарам. В большинстве случаев вместо увеличения продажи товаров наблюдается обратный эффект. Хотя в настоящее время существует мнение, что есть несколько критериев, выполняя которые фирма может получить желаемый эффект и при этом не вызывать отрицательных эмоций у получателя писем:

• Организатором рассылки должен являться поставщик услуг электронной почты;
• Хорошо подобранная целевая аудитория (зачем рассылать предложения продажи суперкомпьютеров, к примеру, домохозяйкам);
• В тексте письма должно содержаться предупреждение о регулярности данной рассылки;
• Наконец, предоставление пользователю удобных механизмов блокирования подобных писем.

Не смотря на то, что данные критерии можно оспорить, т.к. они весьма условны, не стоит забывать, что рекламные письма, рассылаемые пользователям с их согласия, не являются спамом.

Реклама незаконной продукции

Несомненно, каждый из нас хотя бы один раз встречался с подобным. Здесь предлагается всё, начиная от, скажем, баз данных крупнейших сотовых операторов и заканчивая контрафактным программным обеспечением.

Антиреклама

В противовес рекламе ставит своей целью всячески помешать объекту атаки (фирме или простому пользователю). Как правило, содержит заведомо ложную информацию с целью опорочить атакуемый объект.

Письма с целью выманивания денег

Принцип довольно прост. Пользователю приходит письмо содержащее информацию о том, что он может получить крупную сумму денег, а отправитель может ему в этом помочь. Далее содержится просьба перевести небольшую часть денежных средств, для, например, оформления документов или под любым другим предлогом. Получение этих денежных средств и есть цель отправителя.

Фишинг

Цель – выманить у получателя конфиденциальную информацию, номера кредитных карт, информацию о профиле в электронных платёжных системах и т.д. Здесь активно используется социальная инженерия.

Распространение вирусов

Цель заразить как можно больше компьютеров, чтобы создать бот-нет или провести Dos атаку.

С развитием Internet развиваются и способы распространения спама. Как и раньше основная доля приходится на рассылку писем по электронной почте. Причём для этого используются не только почтовые серверы, но и «компьютеры-зомби».

Заходя на сайты, довольно часто мы сталкиваемся с всплывающими окнами, которые занимают большую часть экрана, и при закрытии выполняют переадресацию на некую целевую страницу.

Набирает обороты спам в системах мгновенных сообщений, так называемый спим (SPam + Instant Messenger).

В настоящее время стали популярны web-сайты, на которых можно оставлять комментарии (форумы, блоги, социальные сети) или свободно редактируемые – wiki. Благодаря тому, что данные страницы возможно редактировать на них может быть размещён спам. Целью может служить продвижение какого-либо ресурса (в том числе и в поисковых системах), посредством размещения ссылок, всплывающих окон и/или сценариев автоматической переадресации. Так например, если основная тематика сайта, скажем, автомобили, а большинство комментариев содержит рекламу фармацевтических препаратов, то релевантность данного ресурса для поисковых систем будет снижена.

Также спам перешел «границу» Интернета и теперь рассылается и в СМС сообщениях. Это стало возможным, благодаря появлению дополнительной функциональности в системах обмена мгновенными сообщениями, системах голосовой связи, а так же сервисам, предоставляемым самими операторами сотовой связи.

К основным методам распространения спама относятся:

• Рассылка спама вручную.
  Его эффективность невелика и с ним легко бороться, внося ip-адрес и почтовый адрес в чёрный список
• Программы автоматической рассылки спама.
  Могут быть выполнены в виде утилиты под Windows или скрипта для размещения на web-сайте. В сущности, это автоматизированная разновидность метода 1.
• Рассылка спама при помощи сети троянских прокси (Trojan-Proxy) и спам-ботов. Этот метод наиболее популярен и актуален в настоящее время.

Наиболее интересен 3 метод. Для построения сети Trojan-Proxy или спам-ботов, необходимо заразить ими компьютер пользователя. Это можно сделать с помощью: использования уязвимостей в программном обеспечении, установленном на компьютере жертвы; использования специальной программы, которая сама по себе не содержит вредоносного кода, и возможно, содержит какой-либо полезный функционал, но вместе с тем загружает под видом обновлений или в скрытом режиме вирус; использования почтовых и сетевых червей.

В случае заражения компьютера пользователя спам-ботом, последний связывается с сервером владельца, от которого получает информацию, необходимую для дальнейшей работы: список электронных адресов, параметры рассылки, шаблоны писем и так далее. Компьютер с такой программой очень быстро попадает в чёрные списки и у его владельца возникают сложности с отправкой обычной почты. Это особенно актуально для крупных фирм с собственным почтовым сервером. Представьте себе ситуацию, когда крупная компания оказывается «отрезанной» от остального мира, т.е. вся её электронная переписка не отправляется на другие почтовые серверы и не получается от них соответственно. Подобное может произойти, если даже хотя бы у одного корпоративного пользователя окажется заражённый компьютер. Создание сетей таких компьютеров является очень прибыльным бизнесом. Причём деньги можно получить не только предоставляя услуги рассылки спама, но и за продажу как всей сети, так и отдельного бота.

Ещё одна методика рассылки спама, заключается в использовании так называемых троянских прокси (Trojan-Proxy). Они позволяют злоумышленнику работать в сети от имени заражённой машины. По своей сути являются вирусами, т.к. всячески маскируют свое присутствие в системе, под видом системных процессов (наиболее часто под видом winlogon-а). Принцип работы в следующем, открывается на прослушивание некий TCP-порт (номер порта статический или динамический), после чего данный процесс связывается с владельцем и передаёт ему IP-адрес и номер порта, открытого для прослушивания. Затем он работает как обычный Proxy-сервер. Большинство троянских-прокси умеет размножаться по принципу сетевых червей или при помощи уязвимостей в программном обеспечении компьютера жертвы. Стоит упомянуть, что в настоящее время существует множество гибридов, так например спам-бот может обладать возможностью загружать обновления для себя и/или при наступлении некоего события переходить в прокси режим.

Что касается методов борьбы с подобного рода программами, то их присутствие легко детектируется с помощью любого сниффера (программы для пассивного перехвата трафика). В трафике заражённого компьютера будут преобладать SMTP и DNS.

В данной ситуации можно порекомендовать проверить компьютер с помощью антивируса с последними обновлениями баз данных сигнатур вирусов.

Общие рекомендации по борьбе со спамом

На сегодняшний день существует много способов борьбы со спамом, но универсального способа нет.

Создавать так называемые «чёрные списки», для фильтрации сообщений пришедших от определённого автора/адреса электронной почты/IP-адреса и т.п.

Использовать алгоритмы автоматической фильтрации сообщений/комментариев.

Применительно к комментариям можно выделить следующие методы:

• Позволять оставлять комментарии только зарегистрированным пользователям, с последующей проверкой данных комментариев. Если оставленный комментарий не соответствует каким либо критериям допустимости, характерным для каждого отдельного ресурса, то комментарий удаляется/не публикуется. Таким образом на сайте размещаются только проверенные администрацией комментарии. Данный метод может быть усилен путем разрешения оставления комментариев только «доверенными» пользователями, чьи комментарии были одобрены ранее.
• Использовать службы аутентификации. Например такие как Google Account, «Яндекс.Паспорт» и т.д. Самым распространённым на сервис аутентификации TypeKey.
  При регистрации на сайте данного сервиса, пользователь получает возможность оставлять комментарии на всех сайтах, где этот сервис поддерживается. В России используется OpenID. К плюсам использования систем аутентификации следует отнести то, что для доступа к ресурсу нужно зарегистрироваться и подтвердить свою учётную запись, что создает дополнительные трудности спамерам.
• Изменение названий и переменных используемых в скриптах регистрации популярных движков таких как Movable Type и Wordpress. Цель – затруднить спамерам автоматическую публикацию комментариев, так как нужно определить не только новое местоположение скрипта и его название, но и названия внутренних переменных содержащих тело комментария.
• Использование CAPTCHA – полностью автоматизированного публичного теста Тьюринга (Completely Automated Public Turing test to tell Computers and Humans Apart). Несомненно, с ним сталкивался каждый пользователь сети. Он представляет из себя сильно искаженный текст и/или циферно-буквенные комбинации. Данный метод используют все крупные интернет-сервисы, включая Google, MSN, «Яндекс», «Рамблер» и другие. Однако данный тест не является единственным. Так например вам может быть предложена картинка с искаженным текстом математической задачи, сложения целых чисел, или предложен звуковой файл содержащий простое слово, которое вы должны будете записать.

Итак, потенциальной целью спамеров может стать любой. Но если не публиковать свои личные данные, адрес электронной почты, номера ICQ и т.д. то риск подвергнутся атаке будет заметно уменьшен. Также существуют рекомендации использовать несколько адресов электронной почты. Например, один для рабочей документации и важной информации, другой для личной переписки и неформального общения и т.д.

Об авторе

Ирина Сергеевна Раткевич - студентка 3 курса НИЯУ (Национального Исследовательского Ядерного Университета, ранее СарФТИ) Экономико-Математического Факультета, специальность Информационные Системы в Экономике.

В статье описаны технологии тестирования, используемые при разработке статического анализатора кода PVS-Studio. Разработчики инструмента для программистов делятся принциами тестирования собственного программного продукта, которые могут быть интересны разработчикам аналогичных пакетов обработки текстовых данных или исходных кодов.

Введение

Занимаясь разработкой и продвижением программного продукта PVS-Studio, в своих рассказах мы огромное внимание уделяем вопросам качества программного обеспечения, процессам разработки и принципам организации труда программистов. При этом до сих пор закрытым оставался вопрос о том, как же собственно мы сами разрабатываем свой программный продукт? Используем ли те технологии, рекомендации и практики, о которых пишем в статьях? Наконец, относится ли к нам фраза "сапожник без сапог".

В этой статье мы решили рассказать о том, как мы тестируем программный продукт PVS-Studio. С одной стороны, это делается для того, чтобы убедить наших (потенциальных) пользователей в качестве нашего инструмента. С другой стороны - рассказать об успешном опыте применения некоторых практик.

PVS-Studio - это статический анализатор кода, предназначенный для разработчиков современных ресурсоемких приложений на языках Си и Си++ (более подробная информация дана в статье "Учебное пособие по PVS-Studio" [2]). Под современными мы понимаем 64-битные и/или параллельные приложения. Разработка таких программ имеет ряд трудностей, отличных от проблем традиционных программ. Ведь помимо обычных и всем известных ошибок вроде неинициализированных указателей, которые обнаруживаются любым компилятором, есть и специфичные виды проблем.

Речь идет об ошибках в программах, которые проявляются при миграции 32-битных приложений на 64-битные платформы. Или при распараллеливании кода для поддержки многопроцессорности или многоядерности. Разрабатывать такие приложения довольно сложно из-за недостатка инструментов, облегчающих создание 64-битных и параллельных программ. Анализатор PVS-Studio является именно таким инструментом.

Практики тестирования, используемые при разработке PVS-Studio

Разрабатывая PVS-Studio, мы используем пять основных методики тестирования:

1. Статический анализ кода. Странно было бы разрабатывать статический анализатор и не использовать при этом статический анализ.
2. Юнит-тесты уровня классов, методов, функций.
3. Функциональные тесты уровня самостоятельно написанных файлов
4. Функциональные тесты уровня отдельных файлов.
5. Функциональные тесты уровня отдельных сторонних проектов и решений (projects and solutions).

Кратко опишем здесь эти методики.

Поскольку PVS-Studio - это статический анализатор кода, то при его разработке мы также используем методику статического анализа кода для поиска 64-битных проблем в анализаторе. Во-первых, это нужно для того, чтобы нас не упрекнули в том, что мы не пользуемся своим продуктом (шутка). А во-вторых, это реально позволяет находить ошибки до того, как их найдут пользователи.

Юнит-тесты уровня классов, методов функций позволяют нам быть уверенными в том, что добавление новой функциональности не портит имеющийся код. На этом уровне проверяются отдельные программные сущности в виде простеньких маленьких тестов. В общем, самые обычные юнит-тесты.

Функциональные тесты уровня самостоятельно написанных файлов позволяют быстро проверять, что всё, что должно диагностироваться – диагностируется как и раньше. Все обнаруживаемые потенциальные проблемы в коде должны обнаруживаться.

Функциональные тесты уровня отдельных файлов позволяют убедиться, что различные отдельные файлы с кодом полностью и без проблем проверяются анализатором без проблем. Под проблемами здесь понимаются срабатывающие ASSERT, неожиданные сообщения об ошибках, а также падения. Ведь анализатор кода - это такая же программа, как и другие, и падения в ее работе, увы, не редки.

Функциональные тесты уровня отдельных сторонних проектов и решений позволяют убедиться в том, что анализатор все еще умеет проверять проекты, а количество диагностических сообщений от версии к версии изменяется контролируемо, а не хаотично.

Конечно же, помимо этих методик, есть и другие стандартные подходы вроде "зоркий глаз программиста" или "у нас завтра релиз, проверьте ЭТО", но они показали свои недостатки и мы стараемся их не применять.

Теперь же расскажем об используемых приемах более подробно.

Статический анализ кода, выполненный статическим анализатором кода

Заголовок раздела вызывает недоумение? Кто Что же еще может выполнять статический анализ кроме статического анализатора? Однако при разработке инструментов для программистов всегда есть нюансы.

Как вы наверняка знаете, первые версии компиляторов языков программирования редко пишутся сразу же на этих языках. Как правило, для разработки компилятора нового языка используется совсем другой язык, являющийся стандартом на тот момент. Это сегодня все компиляторы Си++, пишутся на Си++, а первая версия была написана на Си.

Точно так же, разрабатывая первую версию статического анализатора кода, мы не могли ее проверить. Именно поэтому первая версия нашего продукта (тогда он назывался еще Viva64) вовсе не была 64-битной! Зато уже версия 1.10, которая появилась 16 января 2007 года, то есть через 17 дней после выпуска первой версии, среди нововведений содержала строку:

• С помощью анализатора Viva64 мы подготовили 64-битную версию Viva64! Но пользователю не надо беспокоиться о выборе подходящей версии. Правильная версия выбирается автоматически во время установки.

Таким образом, как только у нас появился статический анализатор, выявляющий проблемы 64-битного кода, так мы сразу стали проверять им наш же код.

Помогает ли нам статический анализ нашего же продукта? Конечно же, да. Но опять-таки из-за нашей специфики есть нюансы. Поскольку мы сами пишем статьи про то, как надо делать 64-битный код, то 64-битных ошибок в новом коде мы все-таки не допускаем. Однако от применения статического анализа мы извлекаем пользу в плане улучшения диагностики. Например, мы можем посмотреть, какие типы синтаксических конструкций дают явно ложное срабатывание и исключить их диагностирование.

Таким образом, применение статического анализа для разработки статического анализатора оказывается полезным для нас.

Юнит-тесты уровня классов, методов, функций

Юнит-тесты уровня классов, методов, функций представляют собой набор тестов для проверки отдельных логических элементов программы. Вот некоторые примеры функциональности, на которую у нас есть юнит-тесты:

• применение тех или иных правил диагностики потенциально опасных конструкций;
• вычисление типов в выражениях, в операциях приведения типов и т.п.;
• работа операторов (сложение, вычитание и т.п.);
• работа механизмов загрузки и предварительной обработки файлов;
• проверка регистрационной информации;

Естественно, этими областями наши юнит-тесты не ограничиваются, но являются показательными с точки зрения примеров.

Как мы пользуемся этими юнит-тестами? При исправлении ошибки в анализаторе или при добавлении новой функциональности юнит-тесты запускаются в режиме release-сборки. Если тесты проходят без проблем, то тесты запускаются в режиме debug-сборки под отладчиком. Это делается для того, чтобы проверить, не срабатывают ли ASSERT, которых в коде предостаточно. Позднее будет понятно, почему сразу нельзя запускать debug-версию.

Хотя такие тесты позволяют выявить ошибки, они не являются полноценным решением. Дело в том, что у нас в PVS-Studio очень мало юнит-тестов по сравнению с тем, сколько юнит-тестов нужно для проверки "почти компилятора". Поэтому достичь юнит-тестами большого покрытия в нашем случае очень сложно. Это огромная по трудозатратам задача, которую в настоящее время реализовать нет возможности.

Тем не менее, юнит-тесты уровня классов, методов, функций - это первый уровень "обороны" в нашей системе тестирования.

Функциональные тесты уровня самостоятельно написанных файлов

При разработке анализатора кода важно не "потерять" диагностику тех потенциальных ошибок, которые уже давно обнаруживаются. Это достигается за счет функциональных тестов уровня самостоятельно написанных файлов. Абсолютно все обнаруживаемые потенциальные проблемы в виде кода собраны в отдельные файлы. Эти файлы размечены определенным образом. В тех строках, где анализатор кода должен обнаружить ошибки, стоят специальные маркерные символы. Причем в этих маркерах указано, сколько ошибок в данной строке должно быть: одна, две и т.д. Как только из-за ошибки разработчиков что-то перестает диагностироваться, мы сразу же это видим. Раньше в строке номер 17 выдавалось сообщение о двух ошибках, а теперь только об одной. Или наоборот, появились лишние сообщения.

Такой подход очень похож по принципу работы на функциональные тесты уровня отдельных проектов (о которых будет сказано ниже), но отличается очень высокой скоростью работы и тем, что проверяемые файлы написаны (и размечены) самостоятельно.

Кроме того, эту систему можно использовать, разумеется, и при разработке новых диагностических сообщений. Сначала надо в файлах вручную написать код, в котором будет диагностироваться новая ошибка, затем разметить его и можно приступать к реализации собственно диагностики ошибки. Пока реализации нет, система тестирования будет сообщать, что в этом месте должна быть диагностируема ошибка, но ее нет. Как только диагностика появится, тест будет проходить нормально.

Функциональные тесты уровня отдельных файлов

Проверка не отдельных классов/методов или вручную сделанных файлов, а файлов из реальных проектов позволяет нам добиться большего покрытия кода. Четвертым уровнем в нашей системе тестирования является именно такая проверка. В наши тесты включены отдельные полностью препроцессированные файлы из различных проектов: wxWidgets, fox-toolit, CImg, Lame, Boost, CxImage, FreeType и многих других. Также сюда входят препроцессированные файлы, построенные на основе стандартных системных заголовочных файлов (CRT, MFC и так далее).

После добавления новой или исправления старой функциональности программист запускает сначала release-версию тестов, а потом debug-версию. Почему сразу не запускать debug-версию? Очень просто, Debug-версию не запускают сразу потому, что release-версия тестов работает одну минуту, а debug-версия - пять минут.

Тестирование на уровне отдельных файлов – очень мощная вещь. Она позволяет мгновенно выявить ошибку, если в результате развития анализатора какая-то функциональность "отвалилась". Огромное количество ошибок было не допущено благодаря этим тестам.

Функциональные тесты уровня отдельных сторонних проектов и решений

Самая мощная часть нашей системы тестирования - это ее пятый уровень, который представляет собой проверку отдельных проектов и решений (projects and solutions). Именно благодаря этой системе каждая новая версия PVS-Studio как минимум не хуже предыдущей.

Выглядит эта система следующим образом. Имеется несколько десятков проектов и решений различных доступных в интернете программ. Например: Lame, Emule, Pixie, Loki и другие. Каждый из этих проектов проверен с помощью PVS-Studio, результаты проверки (в виде log-файла) сохранены. После установки новой (разрабатываемой версии) запускается специальная разработанная нами система, которая по очереди открывает каждый проект, проверяет его с помощью PVS-Studio, сохраняет результаты, а затем сравнивает их с эталонными. Если есть отличия, то она их записывает в отдельный файл (аналог стандартного diff), который легко можно посмотреть с помощью PVS-Studio и разобраться в причине появления этих отличий.

Например, в новой версии PVS-Studio появилось новое диагностическое сообщение с кодом V118. Мы запускаем систему тестирования, и она должна сообщить, что в некоторых проектах появились сообщения V118. Затем мы вручную просматриваем все изменения в результатах и решаем, правильно ли выдано сообщение V118.

Если же при этом помимо появления сообщения V118 мы видим в результатах, что пропали некоторые сообщения V115, то это означает, что тесты показали недостаток текущей версии программы, и она отправляется обратно на доработку. В случае признания всех изменений справедливыми новые файлы отчетов признаются эталонными, и сравнение выполняется уже с ними.

Эта система имеет и другое назначение. Поскольку продукт PVS-Studio предназначен для работы как в Visual Studio 2005, так и в Visual Studio 2008, то мы всегда проверяем, чтобы диагностические сообщения всегда совпадали в разных версиях Visual Studio. То есть если, к примеру, мы получили во всех проектах 10 000 диагностических сообщений в Visual Studio 2005, то и в Visual Studio 2008 мы должны получить ровно столько же сообщений. Когда выйдет Visual Studio 2010, мы добавим запуск тестов и в этой среде разработки.

Сколько времени занимает такая проверка? На этот вопрос нет однозначного ответа, покольку база этих тестов постоянно растет за счет новых проектов. И, естественно, время работы постоянно увеличивается. Год назад, когда анализатор работал только с использованием одного ядра, тесты выполнялись около часа. Затем мы сделали возможным работу в несколько потоков, и для двухъядерной машины время работы сократилось почти вдвое. Со временем мы добавляли все новые проекты и в тесты. Теперь на той же двухъядерной машине эти тесты отрабатывают чуть больше, чем за час. Все это происходит, естественно, в release-версии. В ближайшее время мы планируем перейти на машину с четырьмя ядрами и добавить еще некоторое число проектов. В таком случае система снова будет работать не меньше часа.

Что дальше?

Известно, что нет предела совершенству. Мы продолжаем развивать нашу систему тестов по всем направлениям. Естественно, мы постоянно увеличиваем базу всех тестов. Кроме того, нам недостает системы тестирования GUI. Ошибки в этой системе не так критичны для анализатора кода, в том смысле, что заметить их можно и глазами. Но в любом случае, для качественного программного продукта необходимо тестировать и GUI. .

Заключение

Из данной статьи вы узнали, как мы тестируем наш статический анализатор кода PVS-Studio. Возможно, наш опыт поможет вам внедрить подобные практики тестирования в своих рабочих проектах. А мы надеемся, что прочитав о том, как мы тестируем PVS-Studio, у вас возникнет желание подробнее познакомиться с нашим инструментом.

Библиографический список

1. Анализатор кода PVS-Studio. http://www.viva64.com/ru/pvs-studio/
2. Учебное пособие по PVS-Studio. http://www.viva64.com/art-4-1-1796251700.html

Завершились летние каникулы, а вместе с ними и очередная молодежная школа-стажировка Intel. Начиная с 2000 года, и вот уже на протяжении 9 лет каждое лето лучшие молодые специалисты получали уникальную возможность проверить свои силы и знания в реальных проектах в одном из центров Intel, расположенных в Москве, Санкт-Петербурге, Нижнем Новгороде, Новосибирске и Сарове. Но этот год особенный – Летняя школа Intel отметила свое десятилетие, обрела новый формат в партнерстве с ведущими вузами страны и получила поддержку местных администраций!

И впервые сообщество Intel® Software Network совместно с академической программой проводит конкурс проектов «Лето с Intel для профессионального роста», к участию в котором приглашаются студенты Летней школы 2009 года.

На протяжении летних солнечных месяцев самые талантливые ребята, собранные со всей нашей необъятной страны, работали над увлекательными проектами. Надеемся, что это время не прошло бесследно и достойным дополнением к летнему отдыху стали новые знания и неоценимый опыт работы в сотрудничестве с международной компанией. Первый шаг в сторону будущей карьеры сделан, и теперь мы предлагаем сделать следующий - вспомнить самые яркие моменты лета и поделиться своими впечатлениями, полученными знаниями и достижениями, приняв участие в конкурсе. Всех представивших свои работы ждут памятные сувениры, а победителю достанется главный приз – нетбук Lenovo* IdeaPad*. Кроме того не забывайте, участие в конкурсе – это достаточно весомый пункт для вашего резюме ;)

Конкурсное задание

Участникам конкурса необходимо опубликовать на сайте сообщества разработчиков программного обеспечения Intel® Software Network техническую статью с описанием хода и результатов разработанного проекта или выполненного исследования. Не забудьте включить в статью рассказ о впечатлениях от стажировки в Летней школе и ее влиянии на дальнейшие профессиональные взгляды. Это увеличит ваши шансы на победу!

Подробнее о задании, оформлении и порядке публикации работ читайте на страницах официальных правил конкурса «Лето с Intel для профессионального роста» и требований к статьям.

Сроки и условия участия

Конкурс «Лето с Intel для профессионального роста» проходит с 7 сентября по 26 октября 2009 года.
Cроки представления конкурсных работ истекают 6 октября 2009 года в 21:00 по московскому времени.
В первой половине октября 2009 года судейская комиссия определит победителей конкурса, занявших первое, второе и третье места.

Для участия в конкурсе необходимо:

• Зарегистрироваться в сообществе Intel® Software Network.
• Заполнить учетную запись участника сообщества Intel® Software Network, включая контактную информацию: ФИО, географический адрес и телефон.
• Опубликовать на сайте Intel® Software Network (http://software.intel.com/ru-ru/) техническую статью с описанием разработанного проекта или выполненного исследования.

Содержание и оформление конкурсных работ должны удовлетворять требованиям, предъявляемым организаторами данного конкурса.
Подробнее о сроках и условиях участия читайте на странице официальных правил конкурса «Лето с Intel для профессионального роста».

Критерии и принципы оценки конкурсных работ

Для определения победителей конкурса будут использованы следующие критерии оценки:

• Оригинальный, инновационный подход к исследованию/разработке;
• Практические результаты, полученные в ходе работы над проектом;
• Оформление статьи, стиль изложения, полнота предоставленных материалов;
• Мнение сообщества, на основании количества просмотров статей и комментариев.

Победителем конкурса является участник, статья которого получила наивысший суммарный рейтинг судейской комиссии с учетом мнения сообщества.
Подробнее о критериях оценки и принципах судейства читайте на странице официальных правил конкурса «Лето с Intel для профессионального роста».

Информация о призах

Никто без приза не останется – всех ждут памятные сувениры. Участники, занявшие первое, второе и третье места получат:

Первое место:

• Нетбук Lenovo IdeaPad S10-2

Второе место:

• Устройство для чтения книг PocketBook 301

Третье место:

• Цифровая фоторамка Sony DPF–D82 Black

Состав жюри

Александр Лазарев, инженер группы поддержки разработки программного обеспечения, Software Solutions Group
В Интел работает около 6 лет, занимается оптимизацией программного обеспечения сторонних производителей. Также работал инженером по тестированию Intel® Threading Tools на приложениях. До Интел занимался тестированием встроенного программного обеспечения средств связи Моторола и Алкатель. Закончил кафедру прикладной матемтики Физико-Механического факультета Санкт-Петебрургского Государственного Технического Университета.

Алексей Александров, старший инженер по ПО, архитектор программных продуктов Intel для анализа производительности приложений.

Николай Куртов, инженер-практикант по ПО. Разработчик библиотеки параллельного программирования Intel® Concurrent Collections for C++.

Валерий Курякин, кандидат физико-математических наук. Работал в Intel менеджером по инициативам в области новых технологий и продуктов. В настоящее время занимается поиском и оценкой новых технологических и бизнес–проектов в области IT-приложений. Был руководителем и инициатором десятков проектов, принимал участие в оценке многих конкурсов.

Максим Перминов, инженер-программист. Работает с приложениями из области HPC (High Performance Computing), занимается их адаптацией к архитектуре процессоров Интел, а также последовательной и параллельной оптимизацией.

Дмитрий Мишура, старший инженер-программист. Область интересов: HPC, вычислительные кластеры, MPI. Занимается предпродажной поддержкой вендоров, оптимизацией ПО, бенчмаркингом.

Андрей Марочко, в разработке ПО с 1992 года, профессионально - с 1999. Работал в различных областях - от численного анализа до сложных GUI решений и от распределенных клиент-серверных систем до написания библиотек для разработчиков. Начал активно использовать многопоточность в конце 90-х. C 2004 года – старший инженер в Интеле, сначала в отделе Threading Tools, а с 2007 - в Threading Runtimes. Основные направления деятельности - развитие функциональности планировщика задач TBB и параллельных алгоритмов, а также поддержка взаимодействия TBB c другими параллельными технологиями (OpenMP, Cilk) и с инстументами анализа корректности и производительности (Thread Checker, Thread Profiler, Parallel Amplifier).

Андрей Чурбанов, старший инженер по программному обеспечению, работает в проекте по реализации стандарта OpenMP в компиляторе Интел.

Роман Шарыгин, инженер программного обеспечения, Software Solutions Group. Работает в команде Performance, Analysis and Threading, которая отвечает за качество выпускаемых продуктов, как уже выпущеных (VTune, Parallel Studio), так и еще готовящихся к выпуску.

Василий Липсюк, старший инженер ПО, работает в SSG-VCSD/CIP/IPP группе.

Дмитрий Оганезов, менеджер сообщества разработчиков ПО Intel Software Network.

Поддержка

Если у вас появятся вопросы к организаторам конкурса, пожелания и замечания, пожалуйста, оставляйте их в специальной ветке форума или в виде комментария к данной статье.

В статье описывается работа над проектом, целью которого было создание инструмента для поиска потенциальных возможностей проведения кэш-оптимизаций, состоящего из трех компонент: инструментатора бинарного кода для сбора статистики доступа к RAM, статистического анализатора данных и графического интерфейса для представления полученных результатов.

Введение

Г. Маркес был прав, говоря, что самое лучшее в нашей жизни происходит неожиданно. И случайно замеченное мной на просторах Интернета приглашение в Летнюю Школу Intel - яркий тому пример. Сегодня, находясь в Иркутске и выбрав тему диплома непосредственно связанную с тематикой моего проекта в Летней Школе, я понимаю, что один месяц, проведенный на стажировке в Новосибирском Академгородке, оказал достаточно сильное влияние на мою дальнейшую деятельность. В этой статье мне бы хотелось познакомить вас с идеей проекта, рассказать о уже проделанной работе, а также о перспективах развития данной темы.

Об идее проекта

«Создание инструмента для поиска потенциальных возможностей проведения кэш-оптимизаций» - таково название проекта, над которым кроме меня работал Антон Астафьев, а курировал проект ментор от Intel Дмитрий Буданов.

В данном случае нам нужно было рассмотреть возможность повышения производительности программы посредством увеличения эффективности доступа к памяти, зависящей от структуры кода. Реализация проекта состояла из реализации трех его компонент, а именно: инструментатора бинарного кода для сбора статистики доступа к RAM, статистического анализатора данных, графического интерфейса для представления полученных данных. В общем виде суть проекта можно представить следующей схемой:

Рис. 1. Суть проекта

Говоря о структуре кода, необходимо сказать о видах существующих цикловых оптимизаций, т.к. именно циклы зачастую оказываются «узкими местами» программы и, изменяя их структуру, в большинстве случаев, можно достичь более эффективной работы программы с памятью. Ниже приведены наиболее известные цикловые оптимизации:

• Loop invariant code motion (вынесение инвариантов цикла) - оптимизация, которая находит и выносит за пределы цикла выражения независящие от индексных переменных цикла;
• Loop fusion (объединение циклов) - объединение циклов, увеличивающее инструкционный параллелизм и позволяющее интенсивнее загружать вычислительные устройства процессора;
• Loop distribution (разбиение циклов) - разбиение циклов способное улучшить производительность за счет улучшения работы с памятью;
• Loop unrolling (развертка цикла) - техника призванная уменьшить количество условных переходов в цикле. Несколько итераций цикла объединяются в одну;
• Loop unswitching (размыкание цикла) - оптимизация, состоящая в вынесении условия за пределы цикла и дублирования тела цикла с помещением соответствующих вариантов в соответствующие ветви условия;
• Loop interchange (Перестановка циклов) - оптимизация, при которой меняется порядок циклов;
• Loop tiling (разбиение цикла на блоки) - метод оптимизации состоящий в разбиении пространства итерирования исходного цикла на небольшие блоки меньшего размера, что позволяет хранить используемые в этих небольших блоках данные в кэше полностью для их неоднократного использования в процессе выполнения блока.

Таким образом, выявив с помощью статистического анализатора и представив визуально наиболее «проблемные» участки программного кода, можно предположить, что эти участки следует рассмотреть на предмет применения одной или ряда цикловых оптимизаций. Не следует забывать, что результаты, полученные при компиляции программы без оптимизаций компилятора и с ними, будут отличаться друг от друга, что в свою очередь позволяет использовать инструмент при тестировании компиляторов.

Средства, способы и алгоритмы реализации

Для реализации первой компоненты нам понадобилась утилита Pin. Pin - Dynamic Binary Instrumentation Tool, утилита, которая внедряется в анализируемый процесс непосредственно перед стартом и позволяет отслеживать выполнение практически любых инструкций, предоставляет API доступа к содержимому регистров, контексту выполнения программы, символьной и отладочной информации. В нашем случае, мы использовали API, позволяющие инструментировать инструкции доступа к памяти.

Таким образом, в БД записывался адрес инструкции программы, происходящей в каждый n-ый момент времени, адрес ячейки памяти, к которой она обращалась и тип доступа. Т.к. при выполнении даже самой простой программы количество происходящих событий измеряется тысячами, то в качестве параметра n задавался шаг, с которым считывалась необходимая нам информация.

Что касается БД, то мы использовали SQLite - свободно распространяемую реляционную базу данных, не использующую парадигму «клиент-сервер», а основанную на встраиваемом движке. SQLite хранит всю базу данных (включая определения, таблицы, индексы и данные) в единственном стандартном файле на том компьютере, на котором исполняется программа.

Наиболее сложным и самым важным оказалось создание статистического анализатора полученных данных, функция которого заключалась в выявлении областей (кластеров) с наибольшей плотностью обращения инструкций к сегменту памяти. В итоге нами были предложены следующие реализации:

Реализация №1: Определение границ кластеров по каждому измерению с помощью фильтра LoG, фильтрация по плотности наполнения областей.

Фильтр LoG (Laplacian of Gaussian) - сглаживание ряда данных по методу Гаусса, взятие второй производной и определение границ кластера по смене её знака. Чтобы применить фильтр формируются временные таблицы следующей структуры: адрес инструкции, число её повторений (для выявления диапазонов адресов инструкций) и адрес ячейки памяти, число обращений к этой ячейки (для выявления диапазонов адресов ячеек памяти).

Реализация №2: Сортировка собранной статистики пространственным деревом поиска (окто-деревом), фильтрация по плотности и восходящее объединение кластеров.

Кластеризацию на окто-дереве можно описать следующими характеристиками:

• 3D пространство данных;
• Равномерное распределение по каждому измерению - O(n);
• Заполнение дерева - O( n x Log₈n ) ~ 7n;
• Автоматическая балансировка загрузки памяти;
• Связная структура для быстрого объединения;
• Гибкое распараллеливание;
• Использование гипотезы λ-компактности: критерии одинаковой плотности и близости объемов.

Результат обеих реализаций сведен к единому формату - списку кластеров. Кластер представляет собой пересечене диапазонов времени, адресов инструкций и адресов данных.

Надо сказать, что вопрос наиболее эффективного метода обработки данной статистики еще не закрыт и является основным направлением нашего дальнейшего исследования в этом проекте. В рамках Летней Школы мы представили результаты, полученные методами, описанными выше. Графический интерфейс был разработан на языке Java с помощью библиотек Swing и JfreeChart, в среде NetBeans 6.5.

О проблемах

Думаю, было бы странно, если при работе над проектом не возникло бы ни одного затруднения. В этом проекте мне пришлось впервые столкнуться с достаточно большими объемами данных. Индексация и обработка баз данных занимала довольно много времени на ПК средней производительности. Благодаря тому, что у нас был доступ к использованию кластера, нам удалось в разы сократить время работы инструмента. Кроме того, из-за большого объема данных (миллионы записей) терялась точность выявления проблемных областей. Объем данных в свою очередь был связан с выбором шага инструментации. В итоге было принято решение, менять шаг инструментации в соответствии с размером исследуемого кода.

Результаты

Исследовав предметную область, выбрав средства реализации и устранив возникшие проблемы, мы перешли к реализации задуманного. Благодаря организованной работе команды (Антон занимался реализацией первого компонента и метода, основанного на окто-деревьях, а я реализацией третьего компонента и метода, использующего фильтр LoG) и грамотному управлению проектом со стороны нашего куратора, был создан инструмент, архитектура которого представлена на рис.2.

Рис. 2. Архитектура инструмента

На сегодня, так скажем, в первой версии программы, инструментатор бинарного кода отделен от статистического анализатора и графического интерфейса. То есть инструмент состоит из двух частей. На вход первой, консольной части, подается исполняемый бинарный код, на выходе формируется файл базы данных, содержащий необходимые для статистического анализатора данные и используемый во второй части. Во второй части сначала выбирается файл базы данных, затем метод кластеризации. Результаты формируются в виде таблицы кластеров со значимой плотностью, диаграмм диапазонов адресов памяти и адресов инструкций и графика пересечений этих диапазонов.

Ниже вы видите график пересечений диапазонов и общий вид графического интерфейса.

Рис. 3. График пересечений диапазонов

На графике по оси Х указаны адреса ячеек памяти, а по оси Y адреса инструкций. Синим цветом показано, что два диапазона адресов инструкций обращаются к одному и тому же диапазону адресов памяти. Данное пересечение указывает на потенциальную «проблемную» область.

К сожалению, нам не хватило времени протестировать инструмент на реальных приложениях, на скриншоте представлены результаты, полученные при работе с приложениями тестового набора Polyhedron.

Рис. 4. Общий вид графического интерфейса

Перспективы

Я не случайно написала выше именно о первой версии программы. В рамках Летней Школы был заложен хороший фундамент для дальнейшего исследования данной предметной области и работы над проектом, поэтому останавливаться на достигнутом мы не собираемся. Развивать проект предполагается в следующих направлениях:

• Аналитическая обработка данных. Дальнейшее исследование предметной области и методов анализа данных необходимо для создания более эффективного статистического анализатора.
• Визуализация в 3D. Для представления общей картины нужно будет сформировать куб, измерениями которого будут: адрес инструкции, адрес ячейки памяти, момент времени. Таким образом, интересующие нас фрагменты кода будут представлены в виде наиболее плотных областей в этом кубе. Тип доступа предполагается выделять цветом.
• Объединение компонентов. Следует объединить инструментатор бинарного кода со статистическим анализатором и графическим интерфейсом пользователя, что возможно повлечет за собой незначительные изменения в структуре базы данных.
• Экспертная система для помощи в выявлении потенциальных возможностей кэш-оптимизаций. На данном этапе инструмент предлагает в табличном и графическом виде только факты нахождения проблемных областей, и пользователь сам должен сделать выводы о том, какие корректировки можно провести в структуре кода. Было бы неплохо создать модуль, действующий на основе базы знаний о возможных оптимизациях.
• Тестирование на реальных приложениях. Необходимо уделить больше времени тестированию инструмента, провести сравнительные анализы выполнения на разных аппаратных и программных платформах.

Заключение

Как видите, впереди много интересной работы. Возможно, пройдет время, и на сайте сообщества появится статья о второй версии инструмента, а пока я прощаюсь с вами. Благодарю за внимание.

Об авторе и летней школе Intel

Жданова Наталия Юрьевна, студентка Байкальского Государственного Университета Экономики и Права ( факультет Экономической Кибернетики), проходила стажировку в рамках Летней Школы Intel в Новосибирске. Для меня стажировка в Летней Школе стала самым ярким событием этого лета. Интенсивная работа, интереснейшие лекции и тренинги, общение с единомышленниками, экскурсии - четыре сумасшедших недели за которые я расширила свой кругозор, нашла новых друзей, получила опыт работы в команде, изменила взгляд на науку и многое другое. Если бы стажировка длилась всё лето, я бы не задумываясь провела его с Intel, потому что как оказалось, лето и Intel очень даже совместимы!

Используемая литература и ссылки на ресурсы

1. Презентация «Проект №5: Создание инструмента для поиска потенциальных возможностей проведения кэш-оптимизаций» Астафьев А., Жданова Н.
2. Презентация «Современные оптимизирующие компиляторы» Ануфриенко А.
3. http://www.ixbt.com/soft/intel-parallel-inspector.shtml - «Intel Parallel Inspector - поиск ошибок доступа к памяти» В. Цымбал.
4. http://en.wikipedia.org/wiki/Loop_optimization - Loop optimization.
5. http://www.pintool.org/ - сайт, посвященный утилите Pin(Dynamic Binary Instrumentation Tool.
6. http://www.sqlite.org/ - официальный сайт БД SQLite.
7. http://www.jfree.org/jfreechart/ - официальный сайт графической библиотеки Jfreechart.

В статье рассматриваются вопросы обеспечения безопасности программного кода при его адаптации для 64-битных систем.

Введение

Не будем говорить об угрозе взлома программного обеспечения и о размере вреда, который эта угроза может причинить. Об этом написаны многие книги и статьи. Перейдем сразу к новому практическому вопросу в сфере повышения надежности программного кода, связанному с освоением 64-битных систем. И скорее всего, вас не удивит, что речь пойдет о языках Си/Си++, для которых вопросы обеспечения безопасности стоят наиболее остро.

Из-за ошибок и недочетов программный код при переносе с 32-битных на 64-битные системы может стать более восприимчив к атакам, основанных на переполнении буферов. Это связанно с изменением размеров базовых типов данных, что может дать возможность воспользоваться ранее недоступными путями атаки на код. Другими словами код, которой в рамках 32-битных систем был безопасен и не давал возможности использовать его для целей вторжения в систему, после перекомпиляции для 64-битных систем может начать представлять потенциальную угрозу.

Проблема безопасности 64-битного кода не является новой областью в сфере защиты информации. Проблемы различного поведения кода и возможности его взлома всегда зависели от используемой аппаратной платформы. Но массовый переход на 64-битные системы выделяет задачи по обеспечению безопасности 64-битного кода в отдельную категорию, которая заслуживает повышенного внимания и отдельного исследования. В данной статье мы сделаем попытку коснуться проблем безопасности 64-битного кода и показать разработчикам программного обеспечения и систем защиты на этот новый источник потенциальной опасности при разработке современных 64-битных решений.

Анализ программного кода

Существуют различные подходы к обеспечению безопасности программного кода. Мы остановимся на методе статического анализа кода, так как он наиболее подходит для задачи поиска уязвимостей при переносе кода на другую платформу.

Существует достаточно много различных инструментов статического анализа, обеспечивающих диагностику потенциально опасных участков кода, которые могут быть использованы для различных видов атак. В качестве примера можно привести: ITS4, SourceScope, Flawfinder, АК-ВС [1].

Кстати, недавно познакомился с интересным фактом. Я всегда рассматривал инструменты статического анализа кода, как средства поиска ошибок в программах, с целью сделать ее более надежной и устойчивой к входным данным. Но оказывается, хакеры также используют инструменты статического анализа, но с противоположной целью [2]. Они выявляют потенциально ненадежные места в программах, для дальнейшего их подробного изучения. Вручную просматривать код современных приложений практически нереально из-за их размеров, и статический анализ оказывается им хорошим подспорьем. После дизассемблирования кода, хакеры с помощью статического анализа отсеивают наиболее интересные области кода для изучения. Например, они могут искать код, использующий копирование строк и при этом наличие рядом уменьшение/увеличение регистра или ячейки памяти на единицу. Программисты достаточно часто допускают ошибки при работе со строками, когда приходится резервировать дополнительный байт под терминальный символ 0x00 (конец строки). Этот код обычно содержит магические арифметические комбинации, где присутствует -1 или +1. И такой код конечно очень интересен для подробного изучения хакером, поскольку потенциально он может помочь осуществить атаку на основе переполнения буфера.

Но мы отвлеклись. Статические анализаторы помогают программисту выявить потенциально уязвимые участки кода в своих программах и их пользу нельзя недооценивать. Рассмотрим теперь некоторые примера кода, который станет опасным или даже некорректным при переносе на 64-битную систему.

Примеры некорректного и уязвимого кода

С большой коллекцией ошибок, которые возникают в 64-битных программах можно познакомиться в статьях "20 ловушек переноса Си++ - кода на 64-битную платформу" [3] и "Проблемы 64-битного кода на примерах" [4]. Но в данных статьях акцент сделан на ошибки, которые приводят к неработоспособности программы, а не с точки зрения ее уязвимости для атаки.

К сожалению, автору не удалось найти систематических работ по вопросам обеспечения безопасности 64-битного кода. И, по всей видимости, выделение паттернов уязвимостей, специфичных для 64-битных систем является новой задачей, еще ожидающей различных исследований. Попробуем все-таки рассмотреть некоторые примеры.

Одним из методов атаки может стать передачу в программу большого объема данных, превышающий, например, размер 4 Gb. Разберем пример чтения данных из файла.

void *SpecificMalloc(unsigned int size) {
return malloc(size);
} 
...
char *buf;
size_t len; 
read(fd, &len, sizeof(len)); 
buf = SpecificMalloc(len);
read(fd, buf, len);

Напомним, что в 64-битных системах (Linux, Windows) размер типа int составляет 32-бита, а size_t - 64-бита. Ошибка заключается в приведении типа size_t к типу unsigned int при вызове функции SpecificMalloc. Если размер файла будет больше 4 гигабайт, то при чтении данных из файла мы выйдем за границы массива, что является недопустимой ситуацией. Конечно, ошибка в данном примере очевидна, но пример показывает опасность явного и неявного приведения типов, которое может возникнуть в 64-битном коде, смешено использующие 32-битные и 64-битные типы для хранения размеров, индексов и так далее.

Другая разновидность угроз кроется в использовании фиксированных размеров буферов и магических констант. Особенно этим грешит старый код, написанный с десяток лет назад программистами, которые не задумывались, что когда-то изменится размер указателя или перемененной типа time_t.

Рассмотрим простой пример переполнения буфера с жестко заданным размером:

char buf[9];
sprintf(buf, "%p", pointer);

Да, такое бывает в программах. Особенно в старых.

Приведем другой пример, где использование магического числа 4 приводит к ошибке выделения необходимого объема памяти:

LPARAM *CopyParamList(LPARAM *source, size_t n)
{
  LPARAM *ptr = (LPARAM *)malloc(n * 4);
  if (ptr)
    memcpy(ptr, source, n * sizeof(LPARAM);
  return ptr;
}

Неожиданному изменению может подвергнуться и логика работы программы:

int a = -2;
unsigned b = 1;
ptrdiff_t c = a + b;
if (c == -1)
{
  printf("Case: 32-bit\n");
} else {
  printf("Case: 64-bit\n");
}

В этом неаккуратном коде в зависимости от разрядности платформы будут выполняться различные ветки в оператора 'if'. Согласно правилам языка Си++ выражение "ptrdiff_t c = a + b;" будет вычисляться следующим образом:

• Значение типа int, равное -2 будет преобразовано в тип unsigned со значением 0xFFFFFFFEu.
• Произойдет сложение двух 32-битных значений 0x00000001u и 0xFFFFFFFEu, результатом чего станет число 0xFFFFFFFFu размерностью 32-бита.
• Значение 0xFFFFFFFFu будет помещено в 64-битную переменную знакового типа. Для 32-битной системе это означает, что переменная будет содержать значение -1. В случае 64-битной системы переменная так и будет иметь значение 0xFFFFFFFF.

Подобные эффекты опасны не только в логических выражениях, но и при работе с массивами. Определенное сочетание данных в следующем примере приведет к записи за пределами массива на 64-битнйо системе:

int A = -2;
unsigned B = 1;
int array[5] = { 1, 2, 3, 4, 5 };
int *ptr = array + 3;
ptr = ptr + (A + B);
*ptr = 10; // Обращение к памяти за пределами массива
           // в случае 64-битной среды.

Подобную ошибку можно использовать, если удастся установить некорректное значение переменных A и B таким образом, чтобы произвести запись в желаемую область памяти.

Ошибки в логике программы легко могут возникнуть и в коде обрабатывающем отдельные биты. Следующий тип ошибки связан с операциями сдвига. Рассмотрим пример:

ptrdiff_t SetBitN(ptrdiff_t value, unsigned bitNum) {
  ptrdiff_t mask = 1 << bitNum;
  return value | mask;
}

Приведенный код работоспособен на 32-битной архитектуре и позволяет выставлять бит с номерами от 0 до 31 в единицу. После переноса программы на 64-битную платформу возникнет необходимость выставлять биты от 0 до 63. Но данный код никогда не выставит биты, с номерами 32-63. Обратите внимание, что "1" имеет тип int и при сдвиге на 32 позиции произойдет переполнение. В результате мы получим значение 0 или 1, что зависит от реализации компилятора. Заметим также, что неисправленный код приведет еще к одной интересной ошибке. При выставлении 31-ого бита на 64-битной системе результатом работы функции будет значение 0xffffffff80000000. Результатом выражения "1 << 31" является отрицательное число -2147483648. Это число представляется в 64-битной целой переменной как 0xffffffff80000000.

Потенциально манипулирую с входными данными подобных некорректных функций можно получить недопустимые права, если например, происходит обработка масок прав доступа, заданных отдельными битами.

Если приводимые выше примеры кажутся вам надуманными и нереальными, то предлагаю познакомиться с еще одним кодом (в упрощенном виде), который использовался в реальном приложении в подсистеме UNDO/REDO, хотя выглядит он, пожалуй, наиболее странно:

// Здесь указатели сохранялись в виде строки
int *p1, *p2;
....
char str[128];
sprintf(str, "%X %X", p1, p2);
// А в другой функции данная строка
// обрабатывалась следующим образом:
void foo(char *str)
{
  int *p1, *p2;
  sscanf(str, "%X %X", &p1, &p2);
  // Результат - некорректное значение указателей p1 и p2.
  ...
}

Результатом манипуляций указателями с использованием %X стало некорректное поведение программы на 64-битной системе. Данный пример не столько демонстрирует проблему безопасности 64-битного кода, сколько показывает, как опасны потаенные дебри больших и сложных проектов, которые пишутся многими годами. Если проект достаточно велик и стар, то с большой вероятностью в нем существуют уязвимости и ошибки связанные с предположениями о размерах различных структурах данных, правилах выравнивания данных и много других сюрпризов.

Диагностика уязвимых мест в 64-битном коде

Вначале систематизируем типы целей, которые могут стать доступными для атаки при переносе кода на 64-битную систему:

1. Опасны участки кода с арифметическими выражениями, в которых смешанно используются 32-битные и 64-битные типы данных.
2. Опасны участки кода с адресной арифметикой, где присутствуют операции с 32-битными типами данных.
3. Внимание заслуживают выражения, содержавшие магические константы, которые могут означать размер типов данных, максимально допустимые значения, смещение данных в структурах данных.
4. Целью атаки может стать код содержащий операторы сдвига или иные битовые операции.
5. Потенциальную опасность могут представлять различные операции явного и неявного приведения 32-битных и 64-битных типов между собой.
6. Высокому риску подвержен код, реализующий чтение или ввод данных в которых присутствуют типы, изменившие свой размер на 64-битной системе.

Приведенный список пока нельзя назвать полным, поскольку, это, пожалуй, одна из первых исследовательских статей по теме безопасности кода переносимого на 64-битную систему. Однако даже верификация перечисленных объектов позволит существенно повысить надежность кода и устранить как многие уязвимости, так и ошибки, которые могут возникать даже на корректных данных.

На данный момент нет выделенного продукта для контроля безопасности кода при переносе его на 64-битные системы. Однако существует статический анализатор кода PVS-Studio, который полностью поддерживает диагностику всех описанных в этой статье 64-битных проблем уязвимости.

Программный продукт PVS-Studio представляет собой разработку российской компании ООО "Системы программной верификации" и предназначен для верификации современных приложений, использующих такие технологии, как параллельное программирование (OpenMP) и 64-битные архитектуры [5]. PVS-Studio встраивается в среду Microsoft Visual Studio 2005/2008, а также в справочную систему MSDN.

Входящая в состав PVS-Studio подсистема Viva64, помогает специалисту отслеживать в исходном коде Си/Си++-программ потенциально опасные фрагменты, связанные с переходом от 32-битных систем к 64-битным. Анализатор помогает писать безопасный корректный и оптимизированный код для 64-битных систем.

Возможности PVS-Studio покрывают диагностику описанных ранее проблем уязвимостей в 64-битном программном коде. Диагностические возможности данного анализатора избыточны для решения исключительно задач обеспечения безопасности 64-битного кода, поскольку он предназначен не только для выявления потенциальных ошибок, но и например для поиска неоптимальных структур данных. Впрочем, лишние диагностические сообщения легко отключить, используя настройки.

На всякий случай хочется подчеркнуть, что PVS-Studio предназначен для выявления ошибок, возникающих при переносе 32-битных программ в 64-битные системы или при разработке новых 64-битных программ. Но PVS-Studio не диагностирует ошибки, которые могут возникать при использовании небезопасных на любых платформах функций, таких как sprintf, strncpy и так далее. Для диагностики подобных ошибок не следует забывать про уже упомянутые инструменты, такие как ITS4, SourceScope, Flawfinder, АК-ВС. PVS-Studio дополняет ряд этих инструментов, закрывая брешь в диагностики 64-битных проблем, но не заменяет их.

Заключение

Занимаясь вопросами обеспечения безопасности, никогда не увлекайтесь каким-то одним направлением, будь то статический или динамический анализ, тестирование на некорректных входных данных и так далее. Надежность системы определяется ее самым слабым звеном. Бывает, что надежность системы можно повысить на порядок простым административным методом, например, таким как замок.

Существует толи легенда, толи правда, что однажды в одной компании при аудите безопасности ей была поставлена самая низкая оценка, еще даже до того, как специалисты приступили к проверке, дублируются ли данные, какое программное обеспечение установлено на сервере и так далее. Просто сервер стоял в одной из комнат с незапирающейся дверью, куда мог зайти кто угодно. Почему? Шумел сильно, вот и переставили его подальше от рабочих кабинетов, чтобы не мешал.

Библиографический список

1. Касперски, Крис. Компьютерные вирусы изнутри и снаружи. - СПб. : Питер, 2006. - 526 с. : ил. - ISBN 5-469-00982-3.
2. Хогланд, Грег, Мак-Гроу, Гарри. Взлом программного обеспечения: анализ и использование кода.: Пер. с англ. - М.: Издательский дом "Вильямс", 2005. - 400 с. : ил. - Парал. тит. англ. ISBN 5-8459-0785-3. ББК 32.973.26-018.2.75.
3. Андрей Карпов, Евгений Рыжков. 20 ловушек переноса Си++ - кода на 64-битную платформу. http://www.viva64.com/art-1-1-1958348565.html
4. Евгений Рыжков. Проблемы 64-битного кода на примерах. http://www.viva64.com/art-1-1-1757483679.html
5. Евгений Рыжков. Учебное пособие по PVS-Studio. http://www.viva64.com/art-4-1-1796251700.html

Статья посвящена вопросу оценки сложности и стоимости переноса приложений на 64-битные платформы. Рассматриваются такие аспекты, как доступность тех или иных компонентов приложения, библиотек, средств разработки. Приводится пример использования программного продукта PVS-Studio для оценки миграции. Хотя упомянутый продукт PVS-Studio ориентирован на Си и Си++ приложения в системе Windows, статья также будет полезна разработчикам под Unix и другими системами.

Введение

Фразой "не за горами тот день, когда все разработчики должны будут выпустить 64-битные версии своих приложений" я начинаю многие свои статьи еще с 2006 года, хотя на момент написания статьи подходит к концу год 2009. Жизнь показала, что я не прав. Тот день "за горами". До сих пор очень многие компании так и не выпустили 64-битных версий продуктов. Отчасти этому способствует политика компании Microsoft, которая одинаково успешно зарабатывает деньги как на продаже 32-битных версий Windows, так и 64-битных. Отчасти - тем, что далеко не всем приложениям действительно необходимо иметь 64-битные версии.

Однако по моему опыту общения с людьми, ответственными за принятие решений о необходимости разработки 64-битных версий приложений, я понял, что главным сдерживающим фактором является очень простая вещь. Многие люди просто не знают, как оценить время и стоимость процесса миграции приложения на 64-битную архитектуру. Соответственно, это незнание заставляет их откладывать процесс переноса кода на максимально возможный срок.

В данной статье я расскажу об одном из способов, которые позволяет оценить этот процесс до начала миграции. Ведь точно сказать, сколько времени занимает миграция конкретного приложения, можно только после того, как эта миграция выполнена.

Статья основа на опыте сотрудников компании ООО "СиПроВер" как по переносу различных приложений на 64-битные системы, так и по практике применения анализатора кода PVS-Studio.

"Хьюстон, Хьюстон. Разрешите старт!"

Настоящая статья посвящена оценке процесса миграции, а не самому процессу миграции. Поэтому желающим более детально изучить такой вопрос будет интереснее ознакомиться со статьей "7 шагов по переносу программы на 64-битную систему" [2]. Тем не менее, здесь я использую некоторые положения из той статьи. Прежде чем оценивать нюансы миграции, надо иметь четкие ответы на следующие вопросы:

1. Необходимо ли выполнять именно миграцию кода на 64-битные системы или же достаточно, чтобы 32-битное приложение работало на 64-битной операционной системе?
2. Поддерживает ли используемое в проекте средство разработки генерацию 64-битного кода?
3. Существуют ли 64-битные версии всех используемых в проекте компонентов и библиотек?

Если вы ответили на все эти вопросы "да", то перед вами встает основной вопрос, вынесенный в заголовок статьи.

"Как же оценить процесс 64-битной миграции?"

Итак, у вас есть несколько (десятков) мегабайт исходного кода, готового к миграции. Конфигурации для сборки 64-битного кода пока нет, ни одного компилирующегося в 64-битном режиме модуля, соответственно, тоже. Но прочитав статью "20 ловушек переноса Си++ - кода на 64-битную платформу" [4], вы понимаете, что процесс поиска всех скрытых в коде ошибок будет непростым.

Для того чтобы понять, насколько непростым будет поиск всех ошибок, можно использовать статический анализ кода. Существуют разные анализаторы кода (сравнение анализаторов кода [3]), которые можно использовать при поиске проблем в 64-битном коде, но в моей статье я остановлюсь на анализаторе кода PVS-Studio, поскольку именно его разрабатывает наша компания.

Итак, в PVS-Studio 3.30 появилась возможность обнаружения проблем 64-битного кода даже в 32-битных проектах. Именно эта возможность и позволить оценить сложность миграции ДО этапа создания 64-битной конфигурации проекта. Ранее анализатор PVS-Studio позволял проверять проекты только в 64-битной конфигурации.

Я хочу обратить внимание читателей на то, как работает проверка кода в 32-битном режиме. Прежде всего, вы должны понимать, что эта проверка, конечно же, не может считаться полноценной проверкой, и исправление даже всех обнаруженных проблем не является гарантией работоспособности кода в 64-битном режиме. Ведь в коде любого серьезного приложения будут подобные фрагменты:

#ifdef WIN64  ...  #endif  

Естественно, при проверке в 32-битном режиме подобный код будет пропущен. Вернее будет сказать так: на момент, когда 64-битной конфигурации пока еще нет, такого кода в приложении может не быть. А когда он появится, его могут "забыть" проверить.

Другой важный момент - в зависимости от конфигурации проекта типы данных естественно отличаются. Поэтому проверка в 32-битном и в 64-битном режиме практически всегда будет давать разные результаты.

Однако сильно ли будут различаться эти результаты? По результатам экспериментов, проведенных в нашей компании, мы получили следующие данные: списки диагностических сообщений от анализатора кода PVS-Studio при проверке проектов в 32-битном и в 64-битном режимах совпадают на 95-97%! Это означает, что отличаются не более 5% диагностических сообщений. Эти результаты были получены следующим образом: мы взяли код реальных проектов, проверили его в 32-битном режиме, сохранили список обнаруженных проблем. Затем проверили код этих же проектов в 64-битном режиме, сохранили список обнаруженных проблем. После чего сравнили полученные списки и определили, сколько процентов диагностических сообщений совпало. Поскольку вся процедура делалась в автоматизированном режиме, то количество проанализированных проектов было достаточным (больше 20 проектов с объемом кода в несколько мегабайт каждый). Следовательно, эти цифры внушают доверие.

Конечно же, спешить исправлять выявленные потенциальные ошибки в 32-битной конфигурации проекта не стоит - лучше подождать, пока станет доступна 64-битная конфигурация. А вот оценить, сколько потребуется времени для разбора сообщений от анализатора кода, вполне возможно.

Для получения оценки времени рекомендую поступить следующим образом:

1. Выполнить анализ 32-битной конфигурации проекта с помощью PVS-Studio.
2. В течение одного дня программист, понимающий проблемы 64-битного кода, просматривает сообщения анализатора кода и принимает решение о том, актуальна ли данная ошибка для данного проекта или нет.
3. Общее количество сообщений от анализатора кода делится на количество проанализированных и обработанных программистом сообщений за день.
4. Полученное число - это количество человеко-дней, необходимое для миграции кода приложения на 64-битную платформу.

Разумеется, в данном алгоритме оценки процесса миграции есть слабое место - это программист, который будет в течение одного дня разбирать сообщения от анализатора кода. Поэтому я рекомендую очень серьезно подойти к назначению программиста, ответственного за оценку.

Вот несколько рекомендаций по выбору такого программиста:

1. Он должен быть опытным программистом со стажем работы не менее трех лет и желательно со знанием конкретного проекта, который будет портироваться.
2. Он должен быть знаком с проблемами 64-битного кода. Упоминавшаяся уже ранее статья "20 ловушек переноса Си++ - кода на 64-битную платформу" [4] - хороший источник информации по теме.
3. Желательно, чтобы он понимал принципы работы со статическими анализаторами кода. Это необязательное требование, но понимание технологии статического анализа кода делает оценку процесса миграции более адекватной.

Соблюдение этих рекомендаций позволит получить адекватную оценку стоимости и времени процесса 64-битной миграции приложений.

Заключение

Для лучшего понимания этой статьи следует учитывать несколько моментов:

1. Ни один инструмент (в том числе и PVS-Studio) не может выдавать каких-либо оценок. Оценку всегда выдает человек. Иногда с применением инструментов, иногда - без них.
2. Анализатор кода PVS-Studio не предназначен для оценки процесса 64-битной миграции, он не выдает оценки в часах (днях, месяцах). Это инструмент, выявляющий потенциальные ошибки в 64-битном коде. Но на основе такой информации (при проверке 32-битного проекта) человек уже может давать оценки трудозатрат по переносу проекта.
3. Качество оценки зависит от человека.

Желаю успешной оценки 64-битной миграции кода и надеюсь, что инструмент PVS-Studio вам в этом поможет.

Библиографический список

1. Анализатор кода PVS-Studio. http://www.viva64.com/ru/pvs-studio/ .
2. 7 шагов по переносу программы на 64-битную систему. http://www.viva64.com/art-1-1-1148261225.html .
3. Сравнение диагностических возможностей анализаторов при проверке 64-битного кода. http://www.viva64.com/art-1-1-2853247683.html .
4. 20 ловушек переноса Си++ - кода на 64-битную платформу. http://www.viva64.com/art-1-1-1958348565.html .

Аннотация

Изначально статья должна была носить название "Сравнение диагностических возможностей PVS-Studio (VivaMP) и Intel C/C++ Compiler ("Parallel Lint"). Отсутствие на данный момент достаточного количества информации о "Parallel Lint" ограничило возможности автора, и статья представляет собой предварительный вариант сравнения. Полный вариант статьи с корректным сравнением будет доступен читателю в будущем. Обратите внимание, что содержание статьи актуально на момент публикации. В дальнейшем возможно изменение диагностических возможностей обоих продуктов.

Краткая справочная информация

PVS-Studio (VivaMP) - статический анализатор параллельного Си/Си++ кода, в котором используется технология параллельного программирования OpenMP. Анализатор позволяет диагностировать различные виды ошибок, приводящих к некорректной или неэффективной работе OpenMP программ. Например, анализатор способен выявить некоторые ошибки синхронизации, обнаружить выход исключений за границы параллельных регионов и так далее. VivaMP входит в состав программного продукта PVS-Studio и представляет собой модуль расширения к среде Visual Studio 2005/2008 [1].

Intel C/C++ Compiler ("Parallel Lint") - подсистема статического анализа параллельного OpenMP кода, встроенная в компилятор Intel C/C++ начиная с версии 11.1. Для использования Intel C/C++ "Parallel Lint" необходимо создать специальную конфигурацию проекта, но в остальном работа с Intel C/C++ "Parallel Lint" мало чем отличается от обычной работы с компилятором Intel C/C++. Компилятор встраивается в среду Visual Studio 2005/2008. Более подробно с подсистемой "Parallel Lint" можно познакомиться, посмотрев вебинар Дмитрия Петунина "Static Analysis and Intel C/C++ Compiler ("Parallel Lint" overview)".

Введение

Мне как разработчику анализатора VivaMP было крайне интересно сравнить его диагностические возможности с возможностями подсистемы "Parallel Lint", реализованной в Intel C/C++. Дождавшись, когда Intel C/C++ версии 11.1 стал доступен для скачивания, и найдя время для начала исследований, я приступил к сравнению инструментов. К сожалению, это изучение и сравнение не увенчалось успехом, о чем свидетельствует название статьи. Но я уверен, что разработчики найдут в этой статье много интересной информации.

Для начала исследований я решил испробовать Intel C/C++ на демонстрационном примере ParallelSample, входящем в состав PVS-Studio и содержащем ошибки связанные с использованием OpenMP. Программа ParallelSample содержит 23 паттерна ошибок, которые обнаруживаются анализатором VivaMP. Анализ этого проекта должен подтвердить, что анализаторы осуществляют схожую диагностику и их сравнение корректно.

Подготовка к проверке ParallelSample с помощью Intel C++ "Parallel Lint"

Скачивание и установка пробной версии Intel C/C++ Compiler версии 11.1.038 прошли легко и не вызвали никаких затруднений. Немного удивил размер дистрибутива, равный почти гигабайту. Но это понятно, учитывая, что я выбрал для скачивания самый полный вариант, включающий в себя MKL, TBB, поддержку IA64 и так далее. После завершения установки я решил, прежде чем приступить к анализу, собрать и запустить программу ParallelSample.

Но с компиляцией демонстрационного примера ParallelSample возникли сложности. Компилятор выдал сообщение "Catastrophic error: unable to obtain mapped memory (see pch_diag.txt)", как показано на рисунке 1.

Рисунок 1. Сообщение компилятора, выданное при попытке собрать приложение ParallelSample.

При этом файл pch_diag.txt я у себя не обнаружил и обратился за помощью к Google. И почти сразу обнаружил ветку на форуме Intel, посвященную этой проблеме. Ошибка компиляции связана с использованием предкомпилируемых pch-файлов. В чем именно состоит проблема и как аккуратно изменить настройки, чтобы оставить действующей подсистему предкомпилируемых заголовочных файлов, я разбираться не стал. Для такого маленького проекта как ParallelSample это не имеет значения, и я просто отключил в проекте использование предкомпилируемых заголовков (см. рисунок N2).

Рисунок 2. Отключение предкомпилируемых заголовков в настройках проекта.

После этого проект был успешно собран, хотя сразу запустить его не удалось (см. рисунок 3).

Рисунок 3. Ошибка при первом запуске ParallelSample.

Это произошло потому, что я забыл прописать в окружение пути до необходимых DLL. Для этого следует воспользоваться пунктами "C++ Build Environment for applications running on IA-32" и "C++ Build Environment for applications running on Intel(R) 64", доступными через меню "Пуск", как показано на рисунке 4.

Рисунок 4. Установка окружения для работоспособности приложений, собранных с использованием Intel C++.

Модификация окружения стала последним шагом, после которого приложение ParallelSample стало успешно компилироваться, запускаться и работать. Теперь можно приступить к самому интересному - к запуску "Parallel Lint".

Наиболее удобным вариантом использования Intel C++ "Parallel Lint" является создание отдельной конфигурации проекта. Дело в том, что нельзя одновременно получить исполняемый файл и диагностируемые сообщения от Intel C++ "Parallel Lint". Можно получить что-то одно. Постоянно менять настройки, чтобы собирать EXE-файл или чтобы получить диагностику от "Parallel Lint" - весьма неудобно. Следует пояснить такое поведение.

В "классическом" режиме компилятор создает объектные файлы с кодом, которые затем объединяются с помощью редактора связей (компоновщик). В результате процесс компиляции выглядит как показано на рисунке 5.

Рисунок 5. Стандартный режим работы компилятора и компоновщика.

Для глубокого анализа параллельного кода необходимо владеть информацией обо всех модулях программы. Это позволяет понять, используется ли какая-то функция из одного модуля (cpp-файла) в параллельном режиме из другого модуля (cpp-файла), как показано на рисунке 6.

Рисунок 6. Межмодульное взаимодействие.

Чтобы собрать всю необходимую информацию, Intel C++ использует следующую стратегию. Компилятор по-прежнему создает *.obj файлы, но это не объектные файлы, а файлы, содержащие данные, необходимые для последующего анализа. Именно поэтому сборка исполняемого EXE-файла невозможна. Когда компилятор обработает все *.cpp файлы, вместо редактора связей (компоновщика) начинает работать анализатор кода. Опираясь на данные, содержащиеся в *.obj файлах, он диагностирует потенциальные проблемы и выводит соответствующие сообщения об ошибках. В целом процесс анализа можно представить, как показано на рисунке 7.

Рисунок 7. Сбор данных и последующая их обработка анализатором "Parallel Lint".

Создание новой конфигурации осуществляется с помощью "Configuration Manager", как показано на рисунках 8-10:

Рисунок 8. Запускаем Configuration Manager.

Рисунок 9. Создаем новую конфигурацию с именем "Intel C++ Parallel Lint", на основе существующей.

Рисунок 10. Делаем вновь созданную конфигурацию активной.

Следующий шаг - непосредственная активация анализатора "Parallel Lint". Для этого необходимо перейти во вкладку "Diagnostics" в настройках проекта (см. рисунок N11).

Рисунок 11. Вкладка "Diagnostics" в настройках проекта, где можно активировать "Parallel Lint".

Данная страница настроек содержит пункт "Level of Source Code Parallelization Analysis", задающий уровень анализа параллельного кода. Всего имеется три варианта, как показано на рисунке 12.

Рисунок 12. Выбор уровня диагностики параллельных ошибок.

Я выставил максимальный третий уровень диагностики (см. рисунок N13). Включать анализ заголовочных файлов (Analyze Include Files) я не стал, так как проект ParallelSample содержит ошибки только в *.cpp файлах.

Рисунок 13. Выбран максимальный уровень диагностики.

Анализ проектов и сравнение анализаторов

Подготовка к началу анализа завершена, теперь можно запустить компиляцию проекта, чтобы получить диагностические сообщения. Именно это и было осуществлено, в результате чего был получен список сообщений. Приводить его здесь нет смысла, тем более что он дополнительно содержит предупреждения, не относящиеся к OpenMP.

Из 23 трех примеров, содержащих ошибки, Intel C++ обнаружил 5 из них. Также он обнаружил одну дополнительную ошибку, возникающую в некорректной функции и не диагностируемую VivaMP. Количество ложных срабатываний - 2.

Также я попробовал VivaMP на примере parallel_lint, входящем в состав дистрибутива Intel C++. В этом примере содержатся 6 ошибок. Здесь совпадение было полным. И VivaMP, и Intel C++ обнаружили эти 6 ошибок.

Подведем промежуточный итог. Полное совпадение диагностики на примере parallel_lint (из дистрибутива Intel C++) и совпадение диагностики 5 из 23 ошибок на примере ParallelSample (из дистрибутива PVS-Studio) говорит о том, что выбран верный путь. Данные анализаторы подобны, и их сравнение в сфере анализа параллельного OpenMP кода корректно.

Я приготовился к тому, чтобы начать сравнивать анализатор PVS-Studio (VivaMP) и Intel C++ ("Parallel Lint"). Сравнение я планировал осуществить на основании следующих паттернов ошибок:

1. Все паттерны ошибок, которые диагностируются VivaMP и примеры которых представлены в проекте ParallelSample.
2. Паттерны ошибок, которые мне известны, но пока не реализованы в анализаторе VivaMP. О подобных ошибках можно узнать из статей: "32 подводных камня OpenMP при программировании на Си++" [2] и OpenMP и статический анализ кода [3].
3. Все паттерны ошибок, которые диагностируются Intel C++ ("Parallel Lint") и описание которых должно содержаться в документации к компилятору Intel C++.

Хороший план сравнения. Но меня ждало большое разочарование. Третий пункт оказался невозможным для исследования. Я не смог найти в документации Intel C++ описание тех проверок, которые осуществляет Parallel Lint. Поиск в интернете также не дал результатов. Мне удалось обнаружить только разрозненные примеры, демонстрирующие некоторые возможности Parallel Lint.

Тогда я обратился за помощью в сообщество разработчиков Intel, задав вопрос в форуме, где можно подробнее ознакомиться с Parallel Lint. Ответ был неутешителен:

Presently, there's no such list in our current product release, other than what's presented in the compiler documentation under Parallel Lint section. But, we are developing description and examples for all messages, planned as of now for our next major release. Will keep you updated as soon as the release containing such a list is out. Appreciate your patience till then.

Резюмируя - описание возможностей "Parallel Lint" и примеров нет, и в ближайшее время не будет. Я оказался перед выбором, оставить сравнение и продолжить его, когда появится документация на возможности "Parallel Lint" или провести неполное сравнение, а в дальнейшем пополнить его. Поскольку была проделана уже существенная часть работы, я решил все-таки продолжить написание статьи. В ней я проведу некорректное сравнение анализаторов. И подчеркиваю это. В том числе и названием самой статьи.

Сравнение будет осуществляться на доступных мне на данный момент данных. В будущем, когда данных будет больше, я создам вторую версию этой статьи, где возможности Intel C++ будут учтены более полно. Сейчас сравнение будет осуществлено на основании следующих паттернов ошибок:

1. Все паттерны ошибок, которые диагностируются VivaMP и примеры которых представлены в проекте ParallelSample.
2. Паттерны ошибок, которые мне известны, но пока не реализованы в анализаторе VivaMP. О подобных ошибках можно узнать из статей: "32 подводных камня OpenMP при программировании на Си++" и "OpenMP и статический анализ кода".
3. Разрозненные примеры паттернов ошибок, которые входят в состав демонстрационного примера parallel_lint, а также те, которые мне удалось собрать из статей о "Parallel Lint", найденных мной в интернете.

В таблице 1 представлены результаты некорректного сравнения анализаторов VivaMP и "Parallel Lint". После таблицы будут даны пояснения к каждому из пунктов сравнения. Еще раз подчеркну, что результаты сравнения некорректны. Данные в таблице представлены однобоко. Рассмотрены все ошибки, обнаруживаемые VivaMP и только часть ошибок, обнаруживаемых Intel C++ ("Parallel Lint"). Возможно, Intel C++ ("Parallel Lint") обнаруживает еще 500 неизвестных мне паттернов OpenMP ошибок, и тем самым на порядок превосходит возможности VivaMP.

Таблица 1. Результаты некорректного (неполного) сравнения анализаторов PVS-Studio (VivaMP) и Intel C++ ("Parallel Lint").

Пояснение к пунктам сравнения, представленным в таблице 1

Пункт 1. Забытая директива parallel

Ошибка возникает, когда забыта директива parallel. Эта ошибка относится к классу ошибок допускаемых по невнимательности и приводит к неожиданному поведению кода. Пример, где цикл не будет распараллелен:

#pragma omp for
for(int i = 0; i < 100; i++) { ... }

При этом само по себе отсутствие ключевого слова "parallel" в паре, например со словом "for", вовсе не означает ошибку. Если директива "for" или "sections" находятся внутри параллельной секции, заданной директивой "parallel", то такой код не является подозрительным:

#pragma omp parallel
{
  #pragma omp for
  for(int i = 0; i < 100; i++)
    ...
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1001.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 2. Забытая директива omp

Ошибка возникает, когда явно забыта директива omp. Ошибка выявляется даже просто при компиляции кода (без использования Parallel Lint), но все-таки также учтем ее в нашем сравнении. Ошибка относится к классу ошибок по невнимательности и приводит к неожиданному поведению кода. Пример:

#pragma single

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1002.

Intel C++ (Parallel Lint): диагностируется как warning #161.

Пункт 3. Забытая директива for

Иногда программист может забыть вписать директиву "for", что повлечет к выполнению двух циклов, а не их распараллеливанию. Разумно предупредить программиста, что код содержит потенциальную ошибку. Пример подозрительного кода:

#pragma omp parallel num_threads(2)
for(int i = 0; i < 2; i++)
  ...

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1003.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 4. Множественное распараллеливание циклов

Код, содержащий множественное распараллеливание, потенциально может содержать ошибку или приводить к неэффективному использованию вычислительных ресурсов. Если внутри параллельной секции используется параллельный цикл, то, скорее всего, это избыточно и только снизит производительность. Пример кода, где возможно логично сделать внутренний цикл не параллельным:

#pragma omp parallel for
for(int i = 0; i < 100; i++)
{
  #pragma omp parallel for
  for(int j = 0; j < 100; j++)
    ...
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1004.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 5. Забытые order директивы

Опасным следует считать совместное использование директив "for" и "ordered", если затем внутри цикла заданного оператором for не используется директива "ordered". Пример:

#pragma omp parallel for ordered
for(int i = 0; i < 4; i++)
{
  foo(i);
} 

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1005.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 6. Не подключен заголовочный файл <omp.h>

Отсутствие включения заголовочного файла <omp.h> в файле, где используются директивы OpenMP, например такие как "#pragma omp parallel for" теоретически может привести к ошибке и является плохим стилем.

Если программа использует OpenMP, то она должна импортировать vcomp.lib/vcompd.lib. В противном случае произойдет ошибка на этапе выполенния, если вы используете компилятор Visual C++. Импорт этой библиотеки осуществляется в файле omp.h. Поэтому, если в проекте явно не указан импорт нужных библиотек, то #include <omp.h> должно присутствовать хотя бы в одном из файлов проекта. Или импорт библиотек должен быть явно задан в настройках проекта.

В PVS-Studio данное диагностическое сообщение имеет низкий приоритет и активно только в "Pedantic Mode". Поэтому не будет зря вас беспокоить.

Но несмотря на всю свою редкость, это настоящая ошибка, и именно поэтому она попала в сравнение. Приведу практический пример. Открываем проект parallel_lint, входящий в состав Intel C++. Компилируем его с использованием Visual C++. Запускаем и получаем ошибку при запуске исполняемого файла, как показано на рисунке 14.

Рисунок 14. Результат запуска проекта Primes_omp1, собранного компилятором Visual C++ 2005.

Причина - забытый #include <omp.h>. Замечу, что если собрать проект с использованием Intel C++, ошибок не возникает.

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1006.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 7. omp_set_num_threads внутри параллельной секции

Некорректным является вызов функции omp_set_num_threads внутри параллельной секции, заданного директивой "parallel". В Си++ это приводит к ошибкам во время выполнения программы и ее аварийному завершению. Пример:

#pragma omp parallel
{
  omp_set_num_threads(2);
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1101.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 8. Нечетность количества блокировок и разблокировок

Опасным следует считать нечетное использование функций omp_set_lock, omp_set_nest_lock, omp_unset_lock и omp_unset_nest_lock внутри параллельной секции. Пример ошибочного кода:

#pragma omp parallel sections
{
  #pragma omp section
  {
    omp_set_lock(&myLock);
  }
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1102.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 9. omp_get_num_threads в арифметических операциях

Крайне опасным может являться использование omp_get_num_threads в некоторых арифметических выражениях. Пример некорректного кода:

int lettersPerThread = 26 / omp_get_num_threads();

Ошибка заключается в том, что если omp_get_num_threads вернет, например, значение 4, то произойдет деление с остатком. В результате часть объектов не будет обработано. С более подробным примером можно ознакомиться в статье "32 подводных камня OpenMP при программировании на Си++" или в демонстрационном примере Parallel Sample, входящий в состав дистрибутива PVS-Studio.

Другие выражения, использующие omp_get_num_threads, могут быть вполне корректны. Пример, не вызывающий вывод диагностических сообщений в PVS-Studio:

bool b = omp_get_num_threads() == 2;

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1103.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 10. omp_set_nested внутри параллеьной секции

Некорректным является вызов функции omp_set_nested внутри параллельной секции, заданной директивой "parallel". Пример:

#pragma omp parallel
{
  omp_set_nested(2);
}

Но если функция omp_set_nested находится во вложенном блоке, созданном директивой "master" или "single", то такой код вполне корректен:

#pragma omp parallel
{
  #pragma omp master
  {
    omp_set_nested(2);
  }
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1104.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 11. Параллельное использование общих ресурсов

Опасным следует считать незащищенное использование функций в параллельных секциях, если эти функции используют общие ресурсы. Примеры функций: printf, функции OpenGL.

Пример опасного кода:

#pragma omp parallel
{
  printf("abcd");
}

Пример безопасного кода, когда вызов функции защищен:

#pragma omp parallel
{
  #pragma omp critical
  {
    printf("abcd");
  }
}

Диагностика:

PVS-Studio (VivaMP): частично диагностируется как ошибка V1201.

Intel C++ (Parallel Lint): частично диагностируется как error #12158.

Диангоностика описана как частичная, по следующим причинам:

В VivaMP список опасных функций далеко не полон и требует расширения.

К сожалению, анализатор Parallel Lint выдает ложное предупреждение, когда вызов функции защищен. По поводу полноты списка функций, к сожалению, ничего не известно.

Пункт 12. flush для указателя

Директива flush служит для того, чтобы потоки обновили значения общих переменных. При использовании flush для указателя высока вероятность того, что программист ошибся, считая, что произойдет обновление данных по адресу, на которое ссылается указатель. Обновится значение именно переменной, содержащей указатель. Более того, в стандарте OpenMP явно сказано, что переменная-аргумент директивы flush не должна быть указателем.

Пример:

int *t;
...
#pragma omp flush(t)

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1202.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 13. Использование threadprivate

Директива threadprivate является крайне опасной директивой и ее использование рационально только в крайних случаях. По возможности, стоит избегать использования данной директивы. Более подробно с опасностью threadprivate можно познакомится в статье "32 подводных камня OpenMP при программировании на Си++" [2].

Пример опасного кода:

#pragma omp threadprivate(var)

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1203.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 14. Состояния гонки. Статические переменные

Одна из ошибок состояния гонки. Недопустима инициализация статической переменной в параллельной секции без специальной защиты. Пример:

#pragma omp parallel num_threads(2)
{
  static int cachedResult = ComputeSomethingSlowly();
  ...
}

Корректный пример с использованием защиты:

#pragma omp parallel num_threads(2)
{
  #pragma omp critical
  {
    static int cachedResult = ComputeSomethingSlowly();      
    ...
  }
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1204.

Intel C++ (Parallel Lint): диагностируется как warning #12246.

Пункт 15. Состояние гонки. Общая переменная

Одна из ошибок состояния гонки. Два или более потока модифицируют одну общую переменную, которая специально не защищена. Пример:

int a = 0;
#pragma omp parallel for num_threads(4)
for (int i = 0; i < 100000; i++)
{
  a++;
}

Корректный пример с защитой:

int a = 0;
#pragma omp parallel for num_threads(4)
for (int i = 0; i < 100000; i++)
{
#pragma omp atomic
  a++;
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1204.

Intel C++ (Parallel Lint): диагностируется как warning #12246, warning #12247, warning #12248.

Пункт 16. Состояние гонки. Доступ к массиву

Одна из ошибок состояния гонки. Два или более потока пытаются работать с одними и теми же элементами массива, используя для вычисления индексов различные выражения. Пример:

  int i;
  int factorial[10];
  factorial[0]=1;
  #pragma omp parallel for
  for (i=1; i < 10; i++) {
   factorial[i] = i * factorial[i-1];
  }

Диагностика:

PVS-Studio (VivaMP): не диагностируется.

Intel C++ (Parallel Lint): диагностируется как warning #12246.

Пункт 17. Состояние гонки. Опасная функция

Одна из ошибок состояния гонки. Два или более потока вызывают функцию, принимающую в качестве формального аргумента значение по неконстантной ссылке или неконстантному указателю. При вызове такой функции в параллельной секции в нее передается общая переменная. Никакой защиты при этом не используется.

Пример потенциально опасного кода:

void dangerousFunction(int& param);
void dangerousFunction2(int* param);
int a = 0;
#pragma omp parallel num_threads(4)
{
  #pragma omp for
  for (int i = 0; i < 100000; i++)
  {
    dangerousFunction(a);
    dangerousFunction2(&a);
  }
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1206.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 18. Состояние гонки. Модификация объекта

Одна из ошибок состояния гонки. Два или более потока вызывают неконстантную функцию класса у общего объекта. Никакой защиты при этом не используется.

Пример потенциально опасного кода:

  MyClass obj;
  #pragma omp parallel for num_threads(2)
  for (int i = 0; i < 100000; i++)
  {
    obj.nonConstMethod();
  }

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1207.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 19. Приватные указатели

Опасным следует считать применение директив "private", "firstprivate" и "threadprivate" к указателям (не массивам).

Пример опасного кода:

int *arr;
#pragma omp parallel for private(arr)

Если переменная будет указателем, каждый поток получит по локальной копии этого указателя, и в результате все потоки будут работать через него с общей памятью. Высока вероятность, что в коде имеется ошибка.

Пример безопасного кода, где каждый поток работает со своим собственным массивом:

int arr[4];
#pragma omp parallel for private(arr)

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1209.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 20. Неосторожное применение lastprivate

Директива lastprivate после параллельной секции присваивает переменной значение из лексически последней секции, либо из последней итерации цикла. Код, в котором в последней секции не модифицируется помеченная переменная, по всей видимости, ошибочен.

Пример:

#pragma omp sections lastprivate(a)
{
  #pragma omp section
  {
    a = 10;
  }
  #pragma omp section
  {
  }
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1210.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 21. Бессмысленный flush. Локальные переменные

Бессмысленным следует считать использование директивы flush для локальных переменных (объявленных в параллельной секции), а также переменных помеченных как threadprivate, private, lastprivate, firstprivate.

Директива flush не имеет для перечисленных переменных смысла, так как эти переменные всегда содержат актуальные значения. И дополнительно снижает производительность кода.

Пример:

int a = 1;
#pragma omp parallel for private(a)
for (int i = 10; i < 100; ++i) {
  #pragma omp flush(a);
  ...
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1211.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 22. Бессмысленный flush. Присутсвует неявный flush

Неэффективным следует считать использование директивы "flush" там, где оно выполняется неявно. Случаи, в которых директива "flush" присутствует неявно и в ее использовании нет смысла:

• в директиве barrier;
• при входе и при выходе из секции директивы critical;
• при входе и при выходе из секции директивы ordered;
• при входе и при выходе из секции директивы parallel;
• при выходе из секции директивы for;
• при выходе из секции директивы sections;
• при выходе из секции директивы single;
• при входе и при выходе из секции директивы parallel for;
• при входе и при выходе из секции директивы parallel sections;

Диагностика:

PVS-Studio (VivaMP): не диагностируется.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 23. Исключения. Явный throw

Согласно спецификации OpenMP, все исключения должны быть обработаны внутри параллельной секции. Выход исключения за пределы параллельной секции приведет к сбою в программе и, скорее всего, к ее аварийному останову.

Пример недопустимого кода:

try {
  #pragma omp parallel for num_threads(4)
  for(int i = 0; i < 4; i++)
  {
    throw 1;
  }
}
catch (...)
{
}

Корректный код:

size_t errCount = 0;
#pragma omp parallel for num_threads(4) reduction(+: errCount)
for(int i = 0; i < 4; i++)
{
  try {
    throw 1;
  }
  catch (...)
  {
    ++errCount;
  }
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1301.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 24. Исключения. Оператор new

Согласно спецификации OpenMP, все исключения должны быть обработаны внутри параллельной секции. Оператор "new" в случае ошибки выделения памяти генерирует исключение, и это необходимо учесть при его использовании в параллельных секциях.

Пример ошибочного кода:

try {
  #pragma omp parallel for num_threads(4)
  for(int i = 0; i < 4; i++)
  {
    float *ptr = new (MyPlacement) float[1000];
    delete [] ptr;
  }
}
catch (std::bad_alloc &)
{
}

Более подробную информацию на эту тему можно найти в следующих записях блога разработчиков PVS-Studio:

1. OpenMP и исключения (exceptions)
2. Обработка исключений внутри параллельных секций

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1302.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 25. Исключения. Функции

Согласно спецификации OpenMP, все исключения должны быть обработаны внутри параллельной секции. Если в параллельной секции используется функция, помеченная как явно бросающая исключения, то исключение должно быть обработано внутри параллельной секции.

Пример ошибочного кода:

void MyThrowFoo() throw(...)
{
  throw 1;
}
try {
  #pragma omp parallel for num_threads(4)
  for(int i = 0; i < 4; i++)
  {
    MyThrowFoo();
  }
}
catch (...)
{
}

Диагностика:

PVS-Studio (VivaMP): диагностируется как ошибка V1303.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 26. Забытая инициализация. omp_init_lock

Ошибочным следует считать использование переменных типа omp_lock_t / omp_nest_lock_t без их предварительной инициализации в функциях omp_init_lock / omp_init_nest_lock. Под использованием понимается вызов функции omp_set_lock и так далее.

Пример ошибочного кода:

omp_lock_t myLock;
#pragma omp parallel num_threads(2)
{
  omp_set_lock(&myLock);
  omp_unset_lock(&myLock);
}

Диагностика:

PVS-Studio (VivaMP): не диагностируется.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 27. Забытая инициализация. Локальные переменные

Ошибочным следует считать использование переменных, объявленных в параллельном регионе локальными с использованием директив "private" и "lastprivate" без их предварительной инициализации. Пример:

int a = 0;
#pragma omp parallel private(a)
{
  a++;
}

Диагностика:

PVS-Studio (VivaMP): не диагностируется.

Intel C++ (Parallel Lint): диагностируется как error #12361.

Пункт 28. Забытая инициализация после параллельного региона

Ошибочным следует считать использование переменных после параллельного участка кода, к которым применялась директива "private", "threadprivate" или "firstprivate". Перед дальнейшим использованием они должны быть вновь инициализированы.

Пример некорректного кода:

#pragma omp parallel private(a)
{
  ...
}
b = a;

Диагностика:

PVS-Studio (VivaMP): не диагностируется.

Intel C++ (Parallel Lint): диагностируется как error #12352, error #12358.

Пункт 29. Отсутствие конструктора копирования

Опасным следует считать применение директив "firstprivate" и "lastprivate" к экземплярам классов, в которых отсутствует конструктор копирования.

Диагностика:

PVS-Studio (VivaMP): не диагностируется.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 30. Неэффективное использование критических секций

Неэффективным следует считать использование критических секций или функций класса omp_set_lock, там где достаточно директивы "atomic". Директива atomic работает быстрее, чем критические секции, поскольку некоторые атомарные операции могут быть напрямую заменены командами процессора. Следовательно, эту директиву желательно применять везде, где требуется защита общей памяти при элементарных операциях. К таким операциям, согласно спецификации OpenMP, относятся операции следующего вида:

• x binop= expr
• x++
• ++x
• x--
• --x

Здесь х - скалярная переменная, expr - выражение со скалярными типами, в котором не присутствует переменная х, binop - не перегруженный оператор +, *, -, /, &, ^, |, <<, или >>. Во всех остальных случаях применять директиву atomic нельзя (это проверяется компилятором).

Вообще, с точки зрения убывания быстродействия, средства защиты общих данных от одновременной записи располагаются так: atomic, critical, omp_set_lock.

Пример неэффективного кода:

#pragma omp critical
{
  e++;
}

Диагностика:

PVS-Studio (VivaMP): не диагностируется.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 31. Бессмысленная защита локальных переменных

Любая защита памяти от одновременной записи замедляет выполнение программы, будь то атомарная операция, критическая секция или блокировка. Следовательно, в тех случаях, когда она не нужна, эту защиту лучше не использовать.

Переменную не нужно защищать от одновременной записи в следующих случаях:

если переменная является локальной для потока (а также если она участвует в выражении threadprivate, firstprivate, private или lastprivate);

если обращение к переменной производится в коде, который гарантированно выполняется только одним потоком (в параллельной секции директивы master или директивы single).

Пример, где защита записи в переменную "p" не имеет смысла:

#pragma omp parallel for private(p)
for (i=1; i<10; i++)
{ 
  #pragma omp critical
  p = 0;
  ...
}

Диагностика:

PVS-Studio (VivaMP): не диагностируется.

Intel C++ (Parallel Lint): не диагностируется.

Пункт 32. Лишний reduction

Иногда в коде может использоваться директива reduction, хотя указанные в ней переменные не меняются в параллельном регионе. Это может свидетельствовать как об ошибке, так и просто о том, что какая-то директива или переменная была забыта и не удалена в процессе рефакторинга кода.

Пример, где не используется переменная abcde:

#pragma omp parallel for reduction (+:sum, abcde)
for (i=1; i<999; i++)
{ 
  sum = sum + a[i];
}

Диагностика:

PVS-Studio (VivaMP): не диагностируется.

Intel C++ (Parallel Lint): диагностируется как error #12283.

Заключение

Хотя сравнение двух анализаторов пока нельзя назвать законченным, эта статья позволяет читателю узнать о многих паттернах параллельных OpenMP-ошибок и о методах их выявления на самых ранних этапах разработки. Возможность выявить ошибку на этапе кодирования является сильным преимуществом методики статического анализа, так как эти ошибки могут с большим трудом выявляться на этапе тестирования или вовсе не выявляться весьма продолжительное время.

Рассмотренные инструменты PVS-Studio (VivaMP) и Intel C/C++ ("Parallel Lint") будут крайне полезны разработчикам параллельных программ. Какой инструмент выбрать - зависит от разработчика. К сожалению, эта статья не дает ответ на этот вопрос. Пока можно сформулировать преимущества каждого из анализаторов следующим образом:

Преимущества анализатора Intel C/C++ ("Parallel Lint"):

• анализатор входит в состав компилятора, что позволяет разработчикам, использующим Intel C/C++, без каких либо дополнительных вложений или усилий производить верификацию параллельного кода;
• анализатор собирает вместе данные по всем модулям программы и затем целостно их обрабатывает, что позволяет осуществлять некоторые сложные алгоритмы диагностики;
• авторитет и опыт разработчиков Intel C++ в области параллельных решений не вызывает сомнений.

Преимущества анализатора PVS-Studio (VivaMP):

• возможность проверить проект, разрабатываемый в Visual Studio 2005/2008 без необходимости его предварительной адаптации для сборки компилятором Intel C++;
• разработчики, в том числе и автор статьи, доступны для оперативного общения и могут быстро реализовать в анализаторе те возможности, которые необходимы пользователям;
• в состав анализатора входит подробное описание всех паттернов ошибок с примерами, интегрирующимися в справочную систему MSDN (доступной в online режиме здесь: http://www.viva64.com/content/PVS-Studio-help-ru/contents-ru.html);
• интерфейс PVS-Studio позволяет интерактивно фильтровать диагностические сообщения несколькими методами, сохранять и загружать список предупреждений;
• VivaMP является узкоспециализированным, активно развивающимся анализатором, с постоянно растущей базой паттернов параллельных ошибок.

Библиографический список

1. Евгений Рыжков. Учебное пособие по PVS-Studio. http://www.viva64.com/art-4-1-1796251700.html
2. Алексей Колосов, Евгений Рыжков, Андрей Карпов. 32 подводных камня OpenMP при программировании на Си++. http://www.viva64.com/art-3-1-464379766.html
3. Андрей Карпов, Евгений Рыжков. OpenMP и статический анализ кода. http://www.viva64.com/art-3-1-1177384583.html

Аннотация

Статья поможет читателю разобраться, что представляют собой типы size_t и ptrdiff_t, для чего они нужны и когда целесообразно их использование. Статья будет интересна разработчикам, начинающим создание 64-битных приложений, где использование типов size_t и ptrdiff_t обеспечивает быстродействие, возможность работы с большими объемами данных и переносимость между разными платформами.

Введение

Типы size_t и ptrdiff_t были созданы для того, чтобы осуществлять корректную адресную арифметику. Долгое время было принято считать, что размер int совпадает с размером машинного слова (разрядностью микропроцессора) и его можно использовать в качестве индексов, для хранения размеров объектов или указателей. Соответственно адресная арифметика также строилась с использованием типов int и unsigned. Тип int используется в большинстве обучающих материалов по программированию на Си и Си++ в телах циклов и в качестве индексов. Практически каноническим выглядит пример следующего вида:

for (int i = 0; i < n; i++)
  a[i] = 0;

С развитием микропроцессоров и ростом их разрядности стало нерационально дальнейшее увеличение размерностей типа int. Причин для этого много: экономия используемой памяти, максимальная совместимость и так далее. В результате появилось несколько моделей данных, описывающих соотношение размеров базовых типов языка Си/Си++. В таблице N1 приведены основные модели данных и перечислены наиболее популярные системы их использующие.

Таблица 1. Модели данных (data models)

Как видно из таблицы, не так просто выбрать тип переменной для хранения указателя или размера объекта. Чтобы наиболее красиво решить эту проблему и появились типы size_t и ptrdiff_t. Они гарантированно могут использоваться для адресной арифметики. Теперь каноническим должен стать следующий код:

for (ptrdiff_t i = 0; i < n; i++)
  a[i] = 0;

Именно он может обеспечить надежность, переносимость, быстродействие. Почему - станет ясно из дальнейшего текста статьи.

Тип size_t

Тип size_t - базовый беззнаковый целочисленный тип языка Си/Си++. Является результатом выполнения оператора sizeof. Размер типа выбирается таким образом, чтобы в него можно было записать максимальный размер теоретически возможного массива. Например, на 32-битной системе size_t будет занимать 32-бита, на 64-битной - 64-бита. Другими словами в переменную типа size_t может быть безопасно помещен указатель. Исключение составляют указатели на функции классов, но это особый случай. Тип size_t обычно применяется для счетчиков циклов, индексации массивов, хранения размеров, адресной арифметики.

Максимально допустимым значением типа size_t является константа SIZE_MAX.

Тип ptrdiff_t

Тип ptrdiff_t - базовый знаковый целочисленный тип языка Си/Си++. Размер типа выбирается таким образом, чтобы в него можно было записать максимальный размер теоретически возможного массива. На 32-битной системе ptrdiff_t будет занимать 32-бита, на 64-битной - 64-бита. Как и в size_t в переменную типа ptrdiff_t может быть безопасно помещен указатель, за исключением указателя на функцию класса. Также ptrdiff_t является результатом выражения, где один указатель вычитается из другого (ptr1-ptr2). Тип ptrdiff_t обычно применяется для счетчиков циклов, индексации массивов, хранения размеров, адресной арифметики.

Переносимость size_t и ptrdiff_t

Код созданный с использованием типов size_t и ptrdiff_t является хорошо переносимым. Размер size_t и ptrdiff_t всегда совпадают с размером указателя. По этой причине именно эти типы следует использовать в качестве индексов больших массивов, для хранения указателей и арифметики с указателями.

Разработчики Linux приложений часто используют для этих целей тип long. В рамках 32-битных и 64-битных моделей данных, принятых в Linux это действительно работает. Размер типа long совпадает с размером указателя. Но такой код несовместим с моделью данных Windows и соответственно его нельзя считать хорошо переносимым. Более правильным решением будет использование типов size_t и ptrdiff_t.

Разработчики Windows в качестве альтернативы size_t и ptrdiff_t могут использовать типы DWORD_PTR, SIZE_T, SSIZE_T и так далее. Но желательно также ограничиваться типами size_t и ptrdiff_t.

Безопасность типов ptrdiff_t и size_t в адресной арифметике

Проблемы адресной арифметики стали активно проявлять себя с началом освоения 64-битных систем. Наибольшее число проблем при переносе 32-битных приложений на 64-битные системы связанно с использованием неподходящих для работы с указателями и массивами типов, таких как int и long. Этим проблемы переноса приложений на 64-битные системы не ограничивается, но большинство ошибок связанны именно с адресной арифметикой и работе с индексами.

Возьмем самый простой пример:

size_t n = ...;
for (unsigned i = 0; i < n; i++)
  a[i] = 0;

Если мы работаем с массивом, состоящим более чем из UINT_MAX элементов, то данный код является некорректным. При этом выявить ошибку и предсказать поведение данного кода не так просто. Отладочная (debug) версия зависнет, но редко кто в отладочной версии будет обрабатывать гигабайты данных. А вот рабочая (release) версия в зависимости от настроек оптимизации и особенностей кода, может как зависнуть, так и неожиданно корректно заполнить все ячейки массива, создавая иллюзию корректной работы. В результате в программе появляются плавающие ошибки, возникающие или пропадающие после малейшего изменения кода. Подробнее о таких фантомных ошибках и их опасностях можно познакомится в статье "64-битный конь, который умеет считать" [1].

Пример еще одной дремлющей ошибки, которая проявит себя при определенном сочетании входных данных (значении переменных A и B):

int A = -2;
unsigned B = 1;
int array[5] = { 1, 2, 3, 4, 5 };
int *ptr = array + 3;
ptr = ptr + (A + B); //Error
printf("%i\n", *ptr);

Данный код будет успешно выполняться в 32-битном варианте и печатать на экране число "3". После компиляции 64-битном режиме при выполнении кода возникнет сбой. Рассмотрим последовательность выполнения кода и причину ошибки:

• Переменная A типа int приводится к типу unsigned;
• Происходит сложение A и B. В результате мы получаем значение 0xFFFFFFFF типа unsigned;
• Вычисляется выражение "ptr + 0xFFFFFFFFu". Результат зависит от размерности указателя на данной платформе. В 32-битной программе, выражение будет эквивалентно "ptr - 1" и мы успешно распечатаем число 3. В 64-битной программе к указателю прибавится значение 0xFFFFFFFFu, в результате чего указатель окажется далеко за пределами массива.

Приведенные ошибки можно легко избежать, используя тип size_t или ptrdiff_t. В первом случае, если тип переменной "i" будет size_t, то не возникнет зацикливания. Во втором, если мы используем типы size_t или ptrdiff_t для переменных "A" и "B", то корректно распечатаем число "3".

Сформулируем совет: везде, где присутствует работа с указателями или массивами следуeт использовать типы size_t и ptrdiff_t.

Более подробно с тем, каких ошибок можно избежать, используя типы size_t и ptrdiff_t можно познакомиться в следующих статьях:

• 20 ловушек переноса Си++ - кода на 64-битную платформу [2];
• Безопасность 64-битного кода [3];
• Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Windows [4].

Быстродействие кода, использующего типы ptrdiff_t и size_t

Использование типов ptrdiff_t и size_t в адресной арифметике помимо повышения надежности кода может дать дополнительный выигрыш в производительности. Например, использование в качестве индекса типа int, размерность которого отличается от размерности указателя приводит к тому, что в двоичном коде будут присутствовать дополнительные команды преобразования данных. Речь идет о 64-битном коде, в котором размер указателей стал равен 64-битам, а размер типа int остался 32-битным.

Показать короткий пример преимущества size_t над unsigned не простая задача. Чтобы быть объективным необходимо использовать оптимизирующие возможности компилятора. А два варианта оптимизированного кода часто становятся слишком непохожим, чтобы легко было продемонстрировать отличие. Попытка создать нечто близкое к простому примеру увенчалась успехом только с шестой попытки. И все равно пример не идеален, так как показывает не лишние преобразование типов данных, о которых сказано выше, а то, что компилятор смог построить более эффективный код при использовании типа size_t. Рассмотрим код программы, переставляющий элементы массива в обратном порядке:

unsigned arraySize;
...
for (unsigned i = 0; i < arraySize / 2; i++)
{
  float value = array[i];
  array[i] = array[arraySize - i - 1];
  array[arraySize - i - 1] = value;
}

В примере переменные "arraySize" и "i" имеют тип unsigned. Этот тип легко можно заменить на тип size_t и сравнить небольшой участок ассемблерного кода, показанныый на риснуке 1.

Рисунок 1. Сравнение 64-битного ассемблерного кода при использовании типов unsigned и size_t

Компилятор смог построить более лаконичный код, когда использовал 64-битные регистры. Автор не берется утверждать, что код, созданный при использовании типа unsigned (текст слева), будет работать медленнее, чем код с использованием size_t (текст слева). Сравнить скорость выполнения кода на современных процессорах крайне сложная задача. Но из примера видно, что когда компилятор работает с массивами, используя 64-битные типы, он может строить более короткий и быстрый код.

По личному опыту автора, грамотная замена типов int и unsigned на ptrdiff_t и size_t может дать на 64-битной системе дополнительный прирост производительности до 10%. С одним из примеров увеличения скорости от использования типов ptrduff_t и size_t можно познакомиться в четвертой главе статьи "Разработка ресурсоемких приложений в среде Visual C++" [5].

Рефакторинг кода с целью перехода на типы ptrdiff_t и size_t

Как читатель уже убедился, использование типов ptrdiff_t и size_t имеет ряд преимуществ для 64-битных программ. Но и заменить, скажем все unsigned на size_t - не является выходом. Во-первых, это не гарантирует корректность программы на 64-битной системы. Во-вторых, скорее всего из-за такой замены возникнут новые ошибки, нарушится совместимость форматов данных и так далее. Не стоит забывать, что после такой замены существенно возрастет и объем потребляемой программой памяти. Причем увеличение объема требуемой памяти может замедлить работу приложения, так как в кэш будет помещаться меньше объектов, с которыми идет работа.

Следовательно, внедрение в старый код типов ptrdiff_t и size_t является задачей постепенного рефакторинга, требующего большого количества времени. Фактически необходимо просмотреть весь код и внести необходимые исправления. Такой подход практически является слишком дорогостоящим и неэффективным. Можно предложить 2 варианта:

1. Использовать специализированные инструменты, такие как Viva64, входящий в состав PVS-Studio. Viva64 это статический анализатор кода, обнаруживающий места, где рационально изменить типы данных, чтобы программа была корректна и эффективно работала на 64-битных системах. Подробнее смотрите "Учебное пособие по PVS-Studio" [6].
2. Если 32-битную программу не планируется адаптировать для 64-битных систем, то и нет смысла заниматься рефакторингом типов данных. 32-битная программа не получит никаких преимуществ от использования типов ptrdiff_t и size_t.

Библиографический список

1. Андрей Карпов. 64-битный конь, который умеет считать. http://www.viva64.com/art-1-1-1064884779.html
2. Андрей Карпов, Евгений Рыжков. 20 ловушек переноса Си++ - кода на 64-битную платформу. http://www.viva64.com/art-1-1-1958348565.html
3. Андрей Карпов. Безопасность 64-битного кода. http://www.viva64.com/art-1-1-38488545.html
4. Андрей Карпов, Евгений Рыжков. Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Windows. http://www.viva64.com/art-1-1-329725213.html
5. Андрей Карпов, Евгений Рыжков. Разработка ресурсоемких приложений в среде Visual C++. http://www.viva64.com/art-1-1-640027853.html
6. Евгений Рыжков. Учебное пособие по PVS-Studio. http://www.viva64.com/art-4-1-1796251700.html

Введение
Сборка 64-битной Loki в Microsoft Visual Studio 2005
Проверка 64-битной Loki с помощью Viva64
    1 Некорректно используемая константа LONG_MIN
    2 Некоторые виды магических чисел - ошибка или нет?
    3 Прибавление int к указателю - потенциальная проблема
    4 Использование int для индексации массивов некорректно
    5 Правильные аргументы функций
Библиотека Loki совместима с 64-битными системами - значит программа, использующая ее также совместима?
Выводы

Аннотация

Статья представляет собой отчет о проверки библиотеки Loki на совместимость с 64-битными системами с помощью анализатора кода Viva64 компании ООО "СиПроВер". Содержатся рекомендации пользователям библиотеки. Статья будет полезна также пользователям других библиотек, построенных на шаблонах, так как раскрывает особенности анализа подобных библиотек.

Введение

Библиотека Loki разработана Андреем Александреску как часть книги "Современное проектирование на С++: Обобщенное программирование и прикладные шаблоны проектирования". Аннотация к книге гласит: "В книге изложена новая технология программирования, представляющая собой сплав обобщенного программирования, метапрограммирования шаблонов и объектно-ориентированного программирования на C++. Настраиваемые компоненты, созданные автором, высоко подняли уровень абстракции, наделив язык C++ чертами языка спецификации проектирования, сохранив всю его мощь и выразительность".

Компания ООО "СиПроВер", создающая анализатор кода Viva64 для разработки 64-битных приложений, активно общается с авторами различных программных проектов. Однажды к нам обратился Рич Спозато (Rich Sposato), один из администраторов проекта Loki, и попросил проверить код библиотеки на предмет совместимости с 64-битными системами с помощью нашего инструмента Viva64. Мы сразу же согласились. Ведь это не только возможность принести пользу сообществу разработчиков, но и настоящий "тест выносливости" для нашего анализатора кода Viva64. Всем известно, что библиотека Loki написана с применением самых современных и мощных возможностей языка Си++. И если анализатор Viva64 справится с Loki, то и другие более простые проекты не вызовут никаких проблем.

Надо заметить, что данная статья основана на версии Loki от мая 2009 года (новее, чем официальная на тот момент версия Loki 0.1.7), поэтому в более новых версиях Loki указанные проблемы будут устранены.

Итак, мы скачали последнюю версию Loki из SVN-репозитория и приступили к работе.

Сборка 64-битной Loki в Microsoft Visual Studio 2005

Анализатор кода Viva64 интегрируется в среду разработки Microsoft Visual Studio, поэтому разумно было собрать версию Loki именно для этой среды. В составе пакета Loki есть готовые файлы решений для Visual Studio 2005 и Visual Studio 2008. Однако на момент мая 2009 года эти решения содержат лишь 32-битные конфигурации. Поэтому необходимо в Visual Studio создать конфигурации для платформы x64. Добавив нужные конфигурации можно запустить компиляцию 64-битной версии.

Библиотека Loki предназначена для работы на большом количестве различных платформ и собирается с помощью многих наиболее известных компиляторов. Именно поэтому 64-битная версия Loki скомпилировалась практически сразу же. Из 20 проектов, входящих в решение, не собрался только один:

========== Build: 19 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Это был проект SafeFormat:

16>------ Build started: Project: SafeFormat, Configuration: Debug x64 ------
16>Compiling...
16>main.cpp
16>.\main.cpp(255) : error C3066: there are multiple ways 
that an object of this type can be called with these arguments
16>        ..\..\include\loki/SafeFormat.h(109): could be 'Loki::PrintfState<Device,Char> 
&Loki::PrintfState<Device,Char>::operator ()(bool)'
...
16>        while trying to match the argument list '(UInt)'

Текст ошибки несколько сокращен, поскольку полностью он займет целую страницу. Посмотрим на код, который приводит к ошибке:

void test_dword()
{
    typedef signed int Int;
    typedef unsigned int UInt;
    typedef signed long Long;
    typedef unsigned long ULong;
    Int i(0);
    UInt ui(0);
    Long l(0);
    ULong ul(0);
    Printf("%d")(i);
    Printf("%d")(ui); // Проблема в этой строке
    Printf("%d")(l);
    Printf("%d")(ul);
}

Printf - это функция, внутри которой используется макрос LOKI_PRINTF_STATE_FORWARD. С помощью этого макроса задается ряд вспомогательных функций. В нем-то и кроется проблема. Внутри файла SafeFormat.h вместо следующего фрагмента:

#if (defined(_WIN32) || defined(_WIN64))
        LOKI_PRINTF_STATE_FORWARD(unsigned long)
#else

необходимо написать так:

#if (defined(_WIN32) || defined(_WIN64))
#if (defined(_WIN64))
        LOKI_PRINTF_STATE_FORWARD(unsigned int)
#endif
        LOKI_PRINTF_STATE_FORWARD(unsigned long)
#else

После этого исправления ошибка компиляции пропадет и все 20 проектов библиотеки скомпилируются.

Однако среди прочих диагностических сообщений (warnings) компилятора мы видим сообщение, касающееся 64-битного кода:

2>.\CachedFactoryTest.cpp(204) : warning C4267: 'argument' : 
conversion from 'size_t' to 'const int', possible loss of data
2>        .\CachedFactoryTest.cpp(238) : see reference to function template
instantiation 'milliSec typicalUse<Cache>
(Cache &,unsigned int,unsigned int,unsigned int)' being compiled
2>        with
2>        [
2>            Cache=CRandomEvict
2>        ]
2>        .\CachedFactoryTest.cpp(252) : see reference to function template
instantiation 'void displayTypicalUse<CRandomEvict>
(Cache &,unsigned int,unsigned int,unsigned int)' being compiled
2>        with
2>        [
2>            Cache=CRandomEvict
2>        ]

Это сообщение говорит о потенциально опасном преобразовании типа size_t внутри функции typicalUse() в файле CachedFactoryTest.cpp:

// Registering objects
for(size_t i=0;i<objectKind;i++)
  CC.Register(i, createProductNull);

Граница цикла (переменная objectKind) представлена типом unsigned. Поэтому использовать для счетчика цикла переменную типа size_t не имеет смысла. После исправления типа счетчика цикла проблема исчезнет:

 // Registering objects
for(unsigned i=0;i<objectKind;i++)
  CC.Register(i, createProductNull);

После этих небольших исправлений мы имеем 64-битную библиотеку, которая успешно компилируется и не выдает никаких диагностических сообщений (warnings) насчет 64-битности. Но насколько в действительности код библиотеки корректен? Это мы определим с помощью нашего анализатора кода Viva64.

Проверка 64-битной Loki с помощью Viva64

Для того чтобы убедится в совместимости Loki с 64-битными системами, выполним анализ кода с помощью Viva64. Анализатор кода Viva64 предназначен для разработки новых 64-битных приложений и для миграций существующих 32-битных на 64-битную платформу.

Запуск Viva64 для анализа Loki выявил список из 89 потенциально-опасных синтаксических конструкций. Это не значит, что в библиотеке Loki содержится 89 ошибок, связанных с 64-битным кодом. Но все эти 89 мест должен просмотреть разработчик для того, чтобы понять, действительно ли там возможна ошибка или нет. Разумеется, мы проанализировали эти ошибки.

1 Некорректно используемая константа LONG_MIN

Начнем с ошибки, связанной с некорректно используемой константой LONG_MIN в следующей функции:

char* RenderWithoutSign(LOKI_SAFEFORMAT_SIGNED_LONG n, 
    char* bufLast, unsigned int base, bool uppercase)

Она находится в файле SafeFormat.h. Проблема в строке:

if (n != LONG_MIN) {

Тип LOKI_SAFEFORMAT_SIGNED_LONG объявляется как тип, способный вмещать 64-битные значения в 64-битной системе. В Unix-системах (с моделью данных LP64) для этого используют тип long. Но в 64-битных Windows-системах (модель данных LLP64) тип long остался 32-битным. Поэтому в Loki тип LOKI_SAFEFORMAT_SIGNED_LONG объявлен так:

#if defined(_WIN32) || defined(_WIN64)
  #define LOKI_SAFEFORMAT_SIGNED_LONG intptr_t
  #define LOKI_SAFEFORMAT_UNSIGNED_LONG uintptr_t
#else
  #define LOKI_SAFEFORMAT_SIGNED_LONG signed long
  #define LOKI_SAFEFORMAT_UNSIGNED_LONG unsigned long
#endif

Поскольку тип long в 64-битных Windows-системах остался 32-битным, то и константа LONG_MIN задает минимальное значение 32-битной переменной. А это значит, что ее использование некорректно при работе с 64-битными типами (в нашем случае с intptr_t). Решением будет использование собственной константы. Например, исправление может выглядеть так:

#if defined(_WIN32) || defined(_WIN64)
#  define LOKI_SAFEFORMAT_SIGNED_LONG intptr_t
#if defined(_WIN64)
#  define LOKI_SAFEFORMAT_SIGNED_LONG_MIN_VALUE LLONG_MIN
#  define LOKI_SAFEFORMAT_SIGNED_LONG_MAX_VALUE LLONG_MAX
#else
#  define LOKI_SAFEFORMAT_SIGNED_LONG_MIN_VALUE LONG_MIN
#  define LOKI_SAFEFORMAT_SIGNED_LONG_MAX_VALUE LONG_MAX
#endif
...
#else
#  define LOKI_SAFEFORMAT_SIGNED_LONG signed long
#  define LOKI_SAFEFORMAT_SIGNED_LONG_MIN_VALUE LONG_MIN
#  define LOKI_SAFEFORMAT_SIGNED_LONG_MAX_VALUE LONG_MAX
...
#endif

И, соответственно, строку

if (n != LONG_MIN) {

надо заменить на строку

if (n != LOKI_SAFEFORMAT_SIGNED_LONG_MIN_VALUE) {

К счастью и к похвале создателей библиотеки Loki это единственное место, которое заслуживавет исправления. Описанные далее замечания могут быть интересны, но не имеют важности.

2 Некоторые виды магических чисел - ошибка или нет?

Одной из проблем, выявляемой анализатором Viva64 являются магические числа. С точки зрения миграции кода с 32-битной на 64-битную платформу есть ряд чисел, использование которых наиболее опасно. Возможно, где-то в коде программист рассчитывает на определенный размер типа данных, что может вызвать проблему. Те, кто смотрят на сообщения от анализаторов кода, часто жалуются на бессмысленность подобных сообщений. Действительно, какой смысл ругаться анализатору кода на число 4 в подобных строках:

::Loki::ScopeGuard guard4 = ::Loki::MakeGuard( &HasFour, 1, 2, 3, 4 );
::Loki::ScopeGuard guard5 = ::Loki::MakeGuard( &HasFive, 1, 2, 3, 4, 5 );

Но бывают такие конструкции, которые надо анализировать очень тщательно. Например, в файле SafeFormat\main.cpp видим код:

case 'X':
    // TestCase(formatSpec, RandomInt(-10000, 10000));
    // don't test negative values on 64bit systems, because 
    // snprintf does not support 64 Bit values
    TestCase(formatSpec, 
        RandomInt( -10000 * (sizeof(size_t)>4 ? 0 : 1) , 10000));   
    break;
case 'e':

Конкретно в этом месте проблемы, конечно же, нет. Но диагностика магических чисел в анализаторе кода нужна именно для нахождения таких конструкций в коде.

3 Прибавление int к указателю - потенциальная проблема

Файл flex\simplestringstorage.h содержит функцию:

void resize(size_type newSize, E fill)
{
  const int delta = int(newSize - size());
  if (delta == 0) return;
  if (delta > 0)
  {
    if (newSize > capacity())
    {
      reserve(newSize);
    }
    E* e = &*end();
    flex_string_details::pod_fill(e, e + delta, fill);
  }
  pData_->pEnd_ = pData_->buffer_ + newSize;
}

Анализатор Viva64 сообщает о потенциальной проблеме здесь:

flex_string_details::pod_fill(e, e + delta, fill);

Недостаток кода заключается в том, что к указателю e прибавляется переменная delta типа int. Это потенциальная проблема, так как функция pod_fill не сможет обрабатывать объем данных более двух гигабайт (INT_MAX символов). Конечно же, конкретно здесь ошибки, видимо, нет, поскольку вряд ли бывают строки более двух гигабайт. Но лучше все-таки заменить тип переменной delta с int на ptrdiff_t:

const ptrdiff_t delta = ptrdiff_t(newSize - size());

4 Использование int для индексации массивов некорректно

Для доступа к большим массивам данным (более INT_MAX элементов) надо использовать типы ptrdiff_t или size_t. В файле SmallObj\SmallObjBench.cpp присутсвует довольно большой макрос LOKI_SMALLOBJ_BENCH_ARRAY, в котором работа с массивом ведется через индексацию по int. Хотя это лучше исправить, в данном месте это не является ошибкой.

5 Правильные аргументы функций

Внутри файла CachedFactory\CachedFactoryTest.cpp объявлена функция:

template< class Cache >
milliSec typicalUse(Cache &CC, unsigned objectKind, 
                    unsigned maxObjectCount, unsigned maxIteration)

Для параметра objectKind лучше использовать тип size_t. Но поскольку этот код относится к тестам, то какой-либо серьезного недостатка в этом нет.

Библиотека Loki совместима с 64-битными системами - значит программа, использующая ее также совместима?

Все немногие обнаруженные проблемы библиотеки Loki, перечисленные ранее, легко исправимы. Значит ли это, что если в Loki нет никаких 64-битных проблем (а это именно так), то и приложение, использующее эту библиотеку, безопасно с точки зрения 64-битного кода? К сожалению нет!

Все дело в том, что библиотека Loki крайне активно использует шаблоны. А когда анализатор кода разбирает код шаблона, он не всегда может диагностировать проблему. Для полной уверенности анализатору необходимо выполнить инстанцирование шаблонных классов и функций.

Приведем просто пример, не относящийся к библиотеке Loki. Анализатор Viva64 среди прочих проблем в коде может обнаруживать неоптимальные структуры данных:

template <class T>
struct TClass
{
  int m_a;
  T m_b;
  int m_c;
};

Если здесь T имеет тип int, то структура оптимальна. Если же T имеет тип size_t, то структура займет 24 байта, вместо возможных 16 байтах. Тогда в случае большого количества подобных объектов лучше было бы переписать:

template <class T>
struct TClass
{
  T m_b;
  int m_a;
  int m_c;
};

Но проверить это анализатор может только выполнив инстанцирование шаблона. То есть имея лишь объявление класса в заголовке выявит проблему нельзя.

Другой пример, опять же не относящийся к Loki, связанный с приведением типов:

template<typename T1, typename T2>
class TemplateClass
{
public:
	void test1()
	{
		m_a.m_value = m_b.m_value; // Есть ли здесь ошибка?
	}
private:
	T1 m_a;
	T2 m_b;
};

В данном коде ошибка приведения типов может быть, а может и не быть, в зависимости от того, с какими параметрами будет выполнено инстанцирование шаблона TemplateClass. Только анализируя код функции, не выполняя инстанцирование, анализатор не может сообщить об ошибке.

Перечисленные два примера шаблонных классов не относятся к библиотеке Loki, однако важны для понимания принципов работы анализаторов кода. Особенность шаблонных библиотек типа Loki заключается в том, что даже если библиотека полностью совместима с 64-битными системами, это не значит что код, который ее использует, корректен. Это в корне меняет подход к верификации приложений. Если при работе с обычной (не шаблонной) библиотекой достаточно быть уверенным, что библиотека корректна с точки зрения 64-бит для того, чтобы быть уверенным в корректности всего приложения, то с шаблонными библиотеками такой уверенности уже быть не может.

Все это означает, что хотя библиотека Loki и не содержит проблем 64-битного кода, пользовательское приложение, которое ее использует должно быть дополнительно проверено анализатором кода на отсутствие подобных проблем. Ведь ошибки зависят от того, с какими параметрами выполняется инстанцирование шаблонов.

Выводы

По результатам работы сотрудников компании ООО "СиПроВер" над проверкой на совместимость с 64-бибтными системами библиотеки Loki сделаны следующие выводы:

Библиотека полностью совместима с 64-битными системами и не содержит потенциальных ошибок. Указанные в данной статье ошибки, скорее всего, будут очень быстро исправлены.

Анализатор кода Viva64, предназначенный для разработки новых 64-битных и миграции старых 32-битных приложений показал себя очень хорошо при проверке сложного шаблонного кода библиотеки. Это говорит о высоком качестве анализатора кода.

Хотя библиотека Loki и не содержит 64-битных проблем, они возможны в пользовательских приложениях, использующих Loki. Поскольку конечный код зависит от того, с какими параметрами инстанцировались шаблоны, то обязательно надо проверять пользовательские приложения анализатором кода. Только тогда можно быть уверенным в полной совместимости приложения с 64-битными системами.

Благодарность

Благодарим всех, кто принимал участие в анализе библиотеки Loki и в оценке этой работы в команде Loki:

• Спасибо компании ООО "СиПроВер", которая проанализировала код библиотеки Loki и выполнила верификацию ее для работы в 64-битном режиме, в частности: Андрею Карпову и Евгению Рыжкову.
• Спасибо команде Loki: Андрею Александреску, Питеру Кюмелю, Ричу Спозато за совместную работу над проверкой и редактированием статьи, а также ценные замечания.
• Спасибо Ричу Спозато, за координирование всей работы.

Библиографический список

1. Библиотека Loki. http://sourceforge.net/projects/loki-lib/.
2. Анализатор кода Viva64. http://www.viva64.com/viva64-tool.

Данная статья посвящена рассмотрению вопросов создания бизнес-приложений на основе технологии Silverlight. Рассматриваются следующие вопросы:

• применение существующих шаблонов бизнес-приложений к технологии Silverlight;
• тестирование Silverlight приложений и техника разработки приложений через тестирование (TDD);
• применение гибких методов разработки (Agile development: eXtreme Programming (XP), Scrum).

Введение

Этой весной я случайно наткнулась в интернете на интересную ссылку о возможности прохождения стажировки в Intel. Скачав список задач, я решила, что обязательно найду что-нибудь интересное для себя, однако, выбирать долго не пришлось: вторая же задача оказалась идеальным проектом для меня. А звучала она так: «Задача 2: Разработка интранет-приложения с использованием Silverlight». Заинтересовала она меня по двум причинам: во-первых, по своей трудовой деятельности я сталкивалась с технологией Silverlight, но, к сожалению, не было возможности подробно изучить её и попробовать, поэтому очень хотелось углубить свои знания в этой технологии и попробовать применить её. Во-вторых, прочитав описание задачи, я поняла, что речь пойдет о бизнес-приложениях. После окончания ВУЗа я видела себя именно в сфере разработки бизнес-приложений и опыт их создания это то, чего мне так не хватало как молодому специалисту. И конечно возможность посмотреть компанию Intel изнутри, пообщаться с людьми, которые там работают, научиться чему-то новому и перенять существующий опыт - это то, чего я не могла упустить. Поэтому недолго думая, я заполнила заявку на участие в Летней школе и так я оказалась в Intel Summer School 2009. Над проектом я работала вместе с Евгением Кречуном. Нашим менеджером и непревзойденным идеалом был Евгений Сорокин. В первый же день перед нами были четко сформулированы основная цель и задачи проекта.

Итак, основной целью проекта было исследование технологии Silverlight на предмет применимости для разработки бизнес-приложений. Для решения поставленной цели необходимо было решить следующие задачи:

• Исследовать существующие шаблоны проектирования бизнес-приложений для создания хорошо масштабируемой и гибкой архитектуры бизнес-приложения.
• Освоить технику разработки приложений через тестирование (Test Driving Development), которая позволяет писать более качественный код и снизить риск появления ошибок.
• Научиться методам гибкой разработки (Agile development: eXtreme Programming (XP), Scrum).
• Разработать прототип Silverlight-приложения; Мы были полны одержимого интереса и энергии и хотелось, как можно быстрее приступить к работе.

Разработка прототипа бизнес-приложения

Итак, основной нашей задачей было исследовать технологию Silverlight и определить насколько она подходит для создания бизнес приложений, а также разработать прототип такого приложения. Кодовое название нашего проекта - Dashboard. Основные его функции:

• Сравнение программных проектов по заранее заданным характеристикам с использованием деловой графики.
• Просмотр информации о программных проектах (общее описание и список разработчиков).
• Просмотр и редактирование информации о разработчиках.

Функционал у конечного приложения конечно небольшой, однако, главной целью разработки было показать возможность применения существующих шаблонов и методов к технологии Silverlight. Почему именно Silverlight?

В успехе любого проекта немаловажную роль играет UI, он же - пользовательский интерфейс. И технология Microsoft Silverlight создана именно для созданий интернет и интранет приложений с богатым пользовательским интерфейсом - RIA (Rich Internet application). 10 июля 2009 в 18:00 по московскому времени Microsoft выпустила Silverlight 3 и Microsoft Expression Studio 3, именно эту версию Silverlight мы и решили использовать в нашей разработке. Помимо этого нам понадобились MS Visual Studio 2008 и Silverlight Toolkit.

Начали мы разработку нашего приложения с изучения существующих шаблонов проектирования бизнес-приложений. Для разработки нашего приложения мы использовали шаблон Model View Presenter - шаблон проектирования пользовательского интерфейса, который был разработан для облегчения модульного тестирования и отделения логики от отображения. Помимо шаблона проектирования, немаловажными оказался сам подход к проектированию, а именно ориентация на предметную область - Domain Driven Design, который заключается в следующем:

• основное внимание при разработке должно уделяться предметной области и ее логике;
• разработки в рамках сложных предметных областей должны базироваться на модели предметной области.

Сочетая MVP с основными принципами Domain Driven Design, мы в конечном итоге получили архитектуру приложения, приведенную на рисунке 1.

Рисунок 1. Архитектура приложения

Как видно наша система состоит из двух основных частей: клиентской и серверной.

Клиентская часть представлена Silverlight приложением. Вообще SIlverlight - это кроссплатфоменный и кроссбраузерный плагин, а Silverlight приложение - это .xap файл (по сути дела тот же zip архив, содержащий все ресурсы и сборки приложения), выполняющийся в плагине Silverlight. На момент разработки нашего приложения существовало три типа проектов для Silverlight:

• Silverlight Application - обычное приложение Silverlight.
• Silverlight Class Library - библиотека классов Silverlight, этот тип проекта использовался для слоев: Presentation, Infrastructure, Domain.
• Silverlight Navigation Application - приложение SIlverlight, поддерживающее навигацию, этот тип проекта использовался для слоя View.

Серверная часть представлена WCF сервисом, взаимодействующим с БД через соответствующий слой Data Access. Рассмотрим подробнее слои приложения:

Domain. Этот слой находится в центре нашего приложения и инкапсулирует в себе всю бизнес-логику и знания предметной области. Данный слой содержит все основные бизнес-сущности и бизнес-правила предметной области. В нашем случае классы Solution (программный проект), Measure (показатель), Developer (разработчик), SolutionProfile (профиль проекта) относятся именно к доменным объектам. Вполне естественно, что в приложении должен быть единый домен, поскольку все, что относится к бизнесу описано именно в этом слое. Однако в архитектуре нашего приложения присутствует два домена. Это связано с ограничением технологии Silverlight. Поскольку технология Silverlight работает на своей платформe Silverlight .Net Framework, которая является сильно урезанной версией полноценного .Net Framework, то совместное использование доменных объектов сборками Silverlight и .Net Framework без перекомпиляции невозможно.

Для разрешения данной проблемы и были созданы две сборки Domain: одна используется Silverlight сборками клиентской части, а вторая используется WCF сервисом, работающим под управление полноценного .Net Framework. Однако практически все не так сложно:

• создаем одну сборку Silverlight Class Library;
• создаем вторую сборку обычную .Net Class Library;
• указываем у них одно и то же пространство имен;
• создаем доменные классы в сборке Silverlight;
• затем добавляем ссылки на доменные объекты из .Net Class Library.

В итоге, фактически мы имеем файлы с доменными объектами только в одном экземпляре, а компилируются они в разные сборки. Тем самым наши доменные объекты мы можем использовать как в клиентских сборках Silverlight, так и в WCF сервисе (сборке полноценного .Net Framework).

Presentation. Этот слой содержит в себе всю логику работы интерфейса. В этом слое содержатся классы презентеров (Presenters), которые управляют видами (Views). В этом же слое объявлены интерфейсы IViews, которые реализуются в слое View. Также здесь содержатся плоские объекты, так называемы Presenter Entities, которые обеспечивают более удобное представление доменных объектов для отображения. Вся логика работы интерфейса заложена в этом слое. Поскольку он отделен непосредственно от представления (View), и реализован в виде библиотеки классов, то данный слой идеально поддается модульному тестированию, что естественно является одной из главных особенностей и преимуществ шаблона MVP.

View. Этот слой представляет собой UI нашего приложения. В нем реализуются интерфейсы, объявленные в слое Presenter (IViews). Сам View содержит в себе минимум логики (Passive View), и имеет только простые свойства, для отображения данных.

Infrastructure. Данный слой содержит классы адаптеров, которые предоставляют и сохраняют доменные объекты по запросу презентеров. Разнообразие адаптеров скрывается от слоя Presenter одним общим фасадом (GOF Facade pattern), что делает работу со слоем Infrastructure очень простой и удобной. Сами интерфейсы фасада и адаптеров объявлены в слое Domain, а в слое Infrastructure содержится реализация этих интерфейсов.

Серверная часть реализована в виде WCF сервиса, который с помощью слоя DataAccess (в нашем случае в качестве ORM мы использовали LINQ to SQL) получает данные из BD, формирует доменные объекты и передает их в клиентскую инфраструктуру. Однако для того чтобы передать доменные объекты необходимо их сериализовать, то есть преобразовать из сложных объектов в строку, а на клиенте в слое Infrastructure соответственно десериализовать строку в доменные объекты. Для сериализации мы использовали класс DataContractSerializer, доступный как в полноценных сборках .Net, так и в сборках Silverlight, что очень важно при интеграции приложения, поскольку сериализация и десериализация доменных объектов происходит как в клиентских сборках, так и в серверных сборках.

Так как мы разрабатывали, используя TDD - разработку приложений через тестирование, то вопросам тестирования Silverlight приложений мы уделили значительную часть нашего рабочего времени и провели исследование в этой области. В итоге мы рассмотрели преимущества и недостатки двух основных платформ для тестирования: MS Unit Test Framework (встроенный в MS Visual Studio) и Silverlight Unit Test Framework. Попробовав обе эти платформы, мы сделали следующие выводы:

MS Unit Test Framework

• Подходит для тестирования библиотек классов Silverlight (class libraries).
• Для тестирования необходимо использовать системные сборки Silverlight (в частности заменять сборки System.Core на соответствующую сборки Silverlight System.Core).

MS Silverlight Unit Test Framework

• Подходит для тестирования пользовательских контроллов, анимации непосредственно из браузера.
• Позволяет тестировать асинхронные вызовы. Silverlight работает асинхронно, это означает что все вызовы, например к сервисам, будут происходить асинхронно, а это означает что это тоже необходимо протестировать. Поэтому MS Silverlight Unit Test Framework предоставляет простой способ написания асинхронных тестов. Необходимо просто наследовать класс с асинхронными тестами от класса SilverlightTest, затем применить соответствующие атрибуты [TestMethod, Asynchronous], указать таймаут, если необходимо, с помощью атрибута [Timeout(5000)] и далее управлять выполнением теста с помощью соответствующих методов EnqueueCallback(), EnqueueConditional(), EnqueueTestComplete(), EnqueueDelay(), TestComplete().
• Позволяет протестировать приложение в различных браузерах.

Agile development

Помимо самой разработки и исследования технологии SIlverlight, хочу рассказать о том, как у нас был поставлен процесс разработки. Как я уже писала выше, одной из наших задач было научиться методам гибкой разработки приложений. Вот о них сейчас и пойдет речь.

Начнем с того что же такое «Agile development»? Что же означает это модное выражение?

Многие программисты, работающие в реальных условиях бизнеса и разрабатывающие бизнес-приложения, знают, что программирование задача не из легких. Очень часто заказчик не может четко и понятно сформулировать свои требования. А многие, казалось бы, уже сформулированные требования противоречат друг другу. Да и правила бизнеса могут меняться в процессе разработки. Зачастую не разбираясь во всех деталях предметной области, программист видит стоящую перед ним проблему по-своему, и соответственно решает её, как он считает, правильным путем. Однако получая релиз программы, заказчик понимает, что программа делает не то, что хотелось бы. И непонимание между клиентом и заказчиком в итоге выливается в ненужный программный продукт. Тем самым, мы можем сделать вывод о том, что программа - это не монолитная и неизменная структура, мы не можем заранее предсказать все требования к конечному продукту, а значит, программисты должны своевременно реагировать на изменение требований. А для этого разрабатываемый программный продукт должен быть достаточно гибок для изменения направления развития и податлив для модификации в целом. Именно на это и нацелены практики гибкой разработки приложений (Agile development).

Существует множество методологий гибкой разработки, подробнее расскажу о тех, с которыми познакомились мы в летней школе Intel, а именно это практики экстремального программирования (XP) и методология Scrum. Практики гибкой разработки:

• Сидеть вместе - Sit together. Это простое правило способствует общению в команде, что является немаловажным фактором успеха команды в целом.
• Информативное рабочее пространство - Informative workspace. Различного рода информационные доски помогают быстро и четко видеть весь проект в целом, а также, на каком этапе идет разработка.
• Парное программирование - Pair programming. Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы (driver), другой (observer) наблюдает, но это не значит, что отдыхает. Он также активно участвует в разработке - следит за ошибками, одновременно делает code review и участвует в решении поставленных задач. В течение работы пары меняются, что усиливает взаимодействие внутри команды, и обеспечивает коллективное владение кодом - все это одни из факторов успеха команды, а соответственно и всего проекта.
• Полная команда - Whole team. В терминах XP «заказчик» это не тот, кто платит за проект, а тот, кто действительно будет работать с создаваемым программным продуктом. Поэтому заказчик - это один из участников команды, он должен быть всегда доступен для ответа на возникающие у разработчиков вопросы.
• Энергичная работа - Energized work. Вся команда работает энергично и не больше 40 часов в неделю.
• Разработка через тестирование - Test Driven Development. Основное правило - пишем тесты до кода, что в результате приводит к созданию компактных и легковесных классов с требуемой функциональностью. Помимо этого, TDD позволяет быстро обнаруживать слабые места в дизайне и безопасно делать рефакторинг кода (code refactoring).

Это основные практики, которые мы старались применять во время стажировки. Хотя команда у нас была небольшая, но, тем не менее, применяя практики XP и Scrum, мы сразу заметили, как повысилась эффективность нашей работы, и наши труды стали давать ощутимый результат. Весь процесс разработки разбивался на небольшие недельные итерации (sprints). Нашим «заказчиком» была группа разработчиков SMG, которой мы каждую неделю рассказывали о наших успехах и показывали достигнутые результаты. Они в свою очередь высказывали нам свои замечания и пожелания. После этого мы планировали работу на следующую итерацию: определяли список user stories, распределяли их по приоритетам, делили их на задачи (tasks) и в конечном итоге получали sprint backlog и так нами любимый burn down chart, который мы непременно хотели «сжечь» как можно быстрее. Казалось бы, ничего сложного, но насколько эти вещи мотивировали нас к работе и повышали нашу производительность. Вот в таких необыкновенно новых, но в то же время интересных условиях мы и работали.

Заключение

Тем самым, за время прохождения стажировки были решены все поставленные задачи, а именно:

• Изучен шаблон проектирования бизнес приложений - Model View Presenter, а также подход к проектированию Domain Driven Design и показана возможность их применения к технологии Silverlight.
• Освоена практика разработки приложений через тестирование (TDD) и продемонстрирована возможность её применения при разработке Silverlight приложений. При этом были изучены платформы для тестирования MS Unit Test Framework и MS Silverlight Unit Test Framework и даны рекомендации по их применению.
• Спроектирован и разработан прототип приложения для сравнения показателей качества исходного кода программных решений SMG, а также для просмотра информации по проектам и их разработчикам.
• И, конечно же, был получен неоценимый опыт в применение гибких методов разработки, в частности XP и Scrum.

В заключение хочу выразить благодарность организаторам Летней Школы за подаренную возможность обучения и приобретения новых знаний с помощью компании Intel. Отдельно хочется выразить огромную благодарность Евгению Сорокину, Антону Бевзюку и всей команде разработчиков SMG за те знания и опыт, которыми они с нами так просто и открыто делились. Спасибо. Все знания, полученные в Летней Школе, уже находят применение в моей трудовой деятельности.

Об авторе

Федореева Мария Александровна. В 2009 году закончила Ивановский Государственный Энергетический Университет по специальности Компьютерное обеспечение вычислительной техники и автоматизированных систем. Летом 2009 года принимала участие в Летней молодежной школе-стажировке Intel в городе Нижний Новгород. Сфера профессиональных интересов: интеллектуальный анализ данных, OLAP технологии, разработка бизнес-приложений на основе SOA технологий, web-технологии, мобильные технологии.