Чем дальше, тем экзотичнее ошибки

02 Ноя 2012

Автор: Андрей Карпов

Когда мы только начинали разрабатывать PVS-Studio, я мог практически моментально определить, что является причиной ложного срабатывания или ошибки. Мог сразу сказать, какая подсистема за это отвечает. Прошло время. Система повзрослела. Произошло неизбежное. Пользователь пожаловался на ошибку, возникающую при работе с PVS-Studio. И первый раз на её поиск ушел не час, не день, а почти неделя. Хоть это и печально, но это неизбежно. Чем больше становится программный проект, тем более сложные взаимосвязи его пронизывают. Ошибки становятся все более сложно воспроизводимыми.

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

Поясню по поводу макросов. Их множественное использование может создавать неестественный код, который никогда не будет написан программистом руками. Например, был случай, когда макрос генерировал в препроцессированном файле строку, длинной в 2 701 375 символов. Мы не ожидали такого подвоха, и одно из диагностических правил решало, что возник вечный цикл, и генерировало исключение. Фактически, ошибка содержалась в механизме, который должен был предотвращать другие ошибки :).

Сейчас мы столкнулись с новым редким случаем. В заголовочных файлах библиотеки Qt есть следующий код:

inline QModelIndex QAbstractItemModel::createIndex(
  int arow, int acolumn, int aid) const
#pragma warning( push ) 
#pragma warning( disable : 4312 )
{ 
  return QModelIndex(arow, acolumn, 
                     reinterpret_cast<void*>(aid), this);
}

Обратите внимание, что две #pragma расположены между объявлением функции и её телом. Так делать можно, так как #pragma можно расположить где угодно. Однако на практике, так пишут достаточно редко.

Чтобы корректно обрабатывать такой код и не пропустить тело функции, в PVS-Studio были внесены соответствующие правки в июне 2011 года. И именно тогда, была сделана ошибка, которую нам пришлось искать несколько дней.

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

Кстати, обратите внимание, у меня хватает смелости сказать, что я облажался. Этот код писал именно я. Почему то другие очень не любят говорить о таких ситуациях. Смотрите, например мою заметку: "Миф второй – профессиональные разработчики не допускают глупых ошибок". Вот я заявляю честно. Я допустил простую и глупую ошибку. И потом мы её искали несколько дней. Я не совершенен и признаю это. Если статический анализатор, такой как PVS-Studio, вылавливает хотя-бы 25% подобных опечаток, это просто замечательно! В данном случае, к сожалению, он не смог догадаться о моем коварстве при играх с указателями. Однако часто он помогает нам и тыкает носом в только что написанный код. Я думаю, он уже сэкономил нам прилично времени, которое мы бы потратили потом на отладку.

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

В PVS-Studio можно задать папки, содержимое которых не следует проверять. По умолчанию в настройках прописаны такие папки, как "libpng", "libjpeg" тому подобное. Это позволяет, во-первых, не выдавать бессмысленные предупреждения на исходный код сторонних библиотек. Во-вторых, если *.h файл находится в непроверяемой папке, мы пропускаем тела inline-функций. Это немного ускоряет работу анализатора.

Вот здесь и крылась беда. Анализатор захотел пропустить тело функции, а вместо этого там встретились слова #pragma. Теоретически, эта ситуация должна была быть корректно обработана. Однако из-за опечатки, возникал нулевой указатель.

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

Выводы для себя

Я буду стараться больше думать над тестами нового кода. Были тесты проверяющие, что мы пропускаем тела функций. Были тесты, проверяющие, как обрабатываются #pragma, расположенные перед телом функции. А вот комплексного теста не было. Раз теста не было, это сказалось более чем через год. И прямо по Макконнеллу, время устранения ошибки выросло в 20 раз (см. эту таблицу). Если бы тест был придуман сразу, ошибка была бы локализована моментально.

#Cpp