Дело в том, что тестовая база проектов – явление довольно устоявшееся у нас. Давно уже написаны статьи про ошибки в eMule, WinMerge, TortoiseSVN... И, казалось бы, что все эти тестовые проекты изучены нами вдоль и поперек. А получается, что нет. Ведь вновь и вновь в коде удается найти новые забавные фрагменты кода.

Вот пример:

void CIrcMain::Disconnect(bool bIsShuttingDown)
{
 m_pIrcSocket->Close();
 if (m_pIrcSocket != NULL)
  delete m_pIrcSocket;
}

Код, в общем-то, может даже и работает. В некоторых случаях. Иногда. Когда m_pIrcSocket не NULL. Правда автор не уверен, что m_pIrcSocket всегда будет не NULL и добавил проверку. Но ПОСЛЕ использования. Соответственно, если данный код будет выполнен при m_pIrcSocket, то получим падение, хотя и проверка на NULL есть.

Еще один пример точного такого же плана:

  if (!frmExist)
  {
    frmExist =
       tag->Find(ID3FID_SYNCEDLYRICS, ID3FN_DESCRIPTION, desc);
  }

  if (NULL != tag && NULL != data)
  {

Здесь сначала разыменовывается переменная tag и лишь затем она проверяется. Вопрос все тот же, если автор уверен, что tag не NULL, то зачем он проверяет, а если не уверен, то проверка должна быть раньше.

Так вот, возвращаясь к вопросу, вынесенному в заголовок заметки. Что поражает меня – так это то, что хотя мы много ошибок в коде УЖЕ нашли в наших тестовых проектах, мы все продолжаем и продолжаем находить новые ошибки. С одной стороны это логично, ведь анализатор развивается и соответственно находит что-то новое. С другой – поразительно. Ведь, казалось бы, мы уже столько смотрели на эти тестовые проекты и неужели в них можно найти что-то новое. Оказывается можно.

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

"А вот и нет, мой любознательный читатель". Сегодняшний пост про 64-битную ошибку в ядре Linux. Чудесный сайт с системой отслеживания ошибок (bug tracking system) разработчиков ядра содержит описание bug 16603 (send of data > 4 GB fails on 64 bit systems). Суть проблемы проста: "Отправка данных с использованием Linux-функции send() приводит к ошибке, если размер данных слишком большой. Функция из glibc выглядит так:

ssize_t send(int sockfd, const void *buf, size_t len, int flags);

Все корректно, размер передается как memsize-тип size_t. Однако этот аргумент сохраняется в структуре msgheader, после чего внутри функции tcp_sendmsg идут строки:

while (--iovlen >= 0) {
                int seglen = iov->iov_len;
                unsigned char __user *from = iov->iov_base;

Здесь длина уже сохраняется в int, что, конечно же, никуда не годится. То есть отправка с помощью send() блока в 5 гигабайт приведет к отправке только 1 гигабайта, а отправка блока в 4 гигабайта не даст ничего (из-за "округления" до нуля).

Конечно, workaround понятен - указывать длину не более 0x8000000, но это ошибка и конечно же ее надо править.

Да, и это не из девяностых пример. Баг открыт в августе 2010 года, относится к ядру версии 2.5. И пока (11 октября 2010) не закрыт. А вы говорите в Linux 64-битных проблем нет...

Однажды после выпуска новой версии статического анализатора кода PVS-Studio, к нам обратился пользователь, жалующийся на то, что наш инструмент не работает на его сложном проекте. Кстати хороший способ для разработчиков оценить полезность программы - если после очередного релиза вам приходит несколько писем с сообщением что что-то не работает и сломалось, то значит ваша программа нужна. Вернемся к программе. Итак, не работает - это значит не находит файлы для анализа. Сначала были вопросы про тип проекта, про установленные дополнительные плагины к Visual Studio. Выяснилось, что у пользователя установлен компилятор Intel C++ Compiler, но дело не в нем. Также у пользователя была установлена CUDA, но и это оказалось не причем. Кстати, проверка простенького демонстрационного проекта работала, хотя проверка вновь созданной пустой болванки проекта - уже не работала.

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

Под конец пятого дня после неоднократного запуска специальной отладочной версии с расставленными printf (ага, это к вопросу о printf vs новомодные крутые инструменты) выяснилось следующее. Наш анализатор для анализа файлов генерирует специальные cmd-скрипы, в которых есть строка вида:

cd e:\projects\mylib

то есть переход в папку проекта. А как раз в этой версии (предыдущая работала у пользователя нормально) мы сильно переписывали механизм генерации этих скриптов. У команды cd есть особенность - она не переходит в папку на другом диске, если не указать опцию "/d". То есть правильно должно быть так:

cd /d e:\projects\mylib

Этот ключ "/d" был в прошлой версии программы, но по ошибке и недосмотру был потерян в новой версии при переписывании. К сожалению, все тесты у нас запускались с того же системного диска, поэтому команда cd без опции "/d" отрабатывала нормально.

Причем для того, чтобы ошибка проявилась надо обязательно открыть проверяемый проект через Visual Studio (File->Open...). Если же открыть проект, выбрав sln-файл, то ошибка не проявлялась, так как при таком открытии рабочая папка совпадала с папкой, указываемой в команде cd скрипта. Поэтому повторить ошибку не удавалось довольно долго.

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

Какие можно выводы сделать из этой истории? Банальные, но начинающим программистам от этого они менее полезными не станут:

1. Если ваша программа не работает у пользователя, то не стоит винить установленные у него на компьютере программы типа CUDA или Intel C++ Compiler. Хотя и они бывают виноваты.
2. Даже если у вас приложение проходит пять разных типов тестов, то это не значит, что оно работает всегда и везде.
3. Никакой программный инструмент не сможет полностью заменить человеческий мозг. Увы.
4. Если пользователи вашей программы сами программисты, то вам повезло! Ну какие еще пользователи знают слова отладочная версия, дамп и прочее?

Но помимо сказанного, у ключа /Wp64 есть еще один недостаток, который путает программистов, которые не знакомы с ним. Это касается проблемы разбора кода, содержащего некоторые шаблоны. Рассмотрим пример.

На просторах интернета, можно найти в комментариях к блогу разработчиков Visual C++ следующий пример:

vector<size_t> vs; // создаем вектор элементов size_t
vector<unsigned int> vi; // создаем вектор элементов unsigned int
size_t s; // есть переменная типа size_t
unsigned int i; // есть переменная типа unsigned int
vs[0] = s; // не должно быть warning
vs[0] = i; // не должно быть warning
vi[0] = s; // должно быть warning (*0)
vi[0] = i; // не должно быть warning
s = vs[0]; // не должно быть warning
i = vs[0]; // должно быть warning (*1)
s = vi[0]; // не должно быть warning
i = vi[0]; // не должно быть warning (*2)

Обращаю внимание, что в 32-битном режиме типы size_t и unsigned int должны совпадать.

Теперь скомпилируем этот код в 32-битном режиме в Visual C++ 2005 и получим следующие сообщения. В строке отмеченной (*1) как и должно:

warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data

Но в строке (*2) выдается также:

warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data

Хотя никакого сообщения здесь быть не должно.

И при этом в строке (*0) "забыто" сообщение.

Если же скомпилировать код в 64-битном режиме, то на строки, отмеченные как (*0) и (*1) как и должно выдается сообщение:

warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data

Автор примера Stephan T. Lavavej говорит о проблемах с реализацией ключа в /Wp64 в шаблонах. Дело в том, что технически ключ компилятора /Wp64 реализуется через специальное ключевое слово __w64, добавляемое к описанию типа:

#ifdef _WIN64
  typedef __int64 MySSizet;
#else
  typedef int __w64 MySSizet; // Add __w64 keyword
#endif

Однако это ключевое слово не вводит нового типа данных, поэтому шаблонные классы vs и vi из этого кода одинаковы:

typedef __w64 unsigned int   size_t;
vector<__w64 unsigned int> vs;
vector<unsigned int> vi;

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

Что делать? В Microsoft Connect заведена ошибка, но как там написано, править ее не будут. Во-первых, не понятно как, а, во-вторых, это актуально только для ключа /Wp64, который объявлен deprecated и будет удален.

Разрабатываемый нами анализатор Viva64 (входящий в состав PVS-Studio), хотя тоже не идеален при работе с шаблонами, в данном случае успешно выдает предупреждения для данного кода, но основываясь на других правилах. В частности, если не отключено предупреждение V101, то он выдает предупреждение при попытке неявного расширения unsigned до типа size_t, что может также скрывать ошибку. Таким образом, анализатор Viva64 выдаст следующее:

std::vector<size_t> vs;
std::vector<unsigned int> vi;
size_t s;
unsigned int i;
vs[0] = s;
vs[0] = i; //V101: Implicit assignment
           //type conversion to memsize type.
vi[0] = s; //V103: Implicit type conversion
           //from memsize to 32-bit type.
vi[0] = i;
s = vs[0];
i = vs[0]; //V103: Implicit type conversion
           //from memsize to 32-bit type.
s = vi[0]; //V101: Implicit assignment
           //type conversion to memsize type.
i = vi[0];

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

std::vector<unsigned int> vi;
for (size_t i = 0; i < 10; i++)
  vi[i] = i;

Здесь компилятор выдает предупреждение:

warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data

Анализатор Viva64 в свою очередь учитывает, что значение переменной "i" лежит в диапазоне [0..10] и данный код не может привести к ошибке. В результате никакие диагностические сообщения не выдаются.

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

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

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

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

В систему сборки make добавилась команда "-j" (или "-jobs"), которая позволяет параллельно выполнять команды.

В среду разработки Microsoft Visual Studio 2005 была добавлена возможность сначала компилировать проекты параллельно, а потом, в версию 2008, уже отдельно и файлы(опция /MP). Или вот, к примеру, пользователи Microsoft Visual C++ 2005 помнят, сколько копий было сломано, когда в этой версии появился модуль IntelliSense. Топик про то, как отключить IntelliSence имеет 120 000 просмотров в форуме MSDN. Все потому, что на однопроцессорной машине эта технология работала не лучшим образом и довольно серьезно тормозила работу. Но с появлением многоядерных машин, все эти дискуссии угасли. Крутится себе IntelliSence на одном ядре, никому не мешает.

И если раньше для ускорения компиляции приходилось использовать всякие сторонние инструменты вроде MPCL или IncrediBuild, то теперь это встроено в средства разработки.

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

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

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

У нас есть база регрессионных тестов из примерно 30 приложений (более 90 проектов) - это исходные коды, которые проверяются анализатором PVS-Studio в автоматическом режиме. Проверка всех этих кодов в версии анализатора для Visual Studio 2008 занимает около двух часов. Используемая машина: процессор с двумя ядрами, четыре гигабайта оперативной памяти и SATA RAID-система (RAID 0). В той же машине еще установлен старый IDE жесткий диск, который никак не использовался, но вынуть из машины его все не было повода.

Однажды по некоторой причине тесты были перенесены с SATA RAID на IDE диск. А после этого переноса мы долго думали, почему тесты стали выполнятся вместо двух часов - четыре! Дело в том, что этот момент совпал с серьезными правками в продукте, и, казалось, что эти правки и приводят к такому сильному падению производительности. Однако вскоре мы вспомнили о смене жесткого диска, и проблема решилась сама собой.

Какое отношение имеет жесткий диск к статическому анализатору кода? Самое прямое. В процессе работы анализатора создаются препроцессированные файлы всех исходных кодов, и анализатор работает уже с ними. Мы посчитали объем препроцессированных файлов в наших тестах в версии для Visual Studio 2008. Он оказался около 7 гигабайт. Естественно запись + чтение такого объема на старом IDE диске вызывает существенное падение производительности.

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