Для получения триального ключа
заполните форму ниже
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

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

Мне интересно попробовать плагин на:
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

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

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

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 раз (см. эту таблицу). Если бы тест был придуман сразу, ошибка была бы локализована моментально.

Последние статьи:

Опрос:

Популярные статьи по теме
Holy C++

Дата: 23 Ноя 2022

Автор: Гость

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

Дата: 01 Ноя 2022

Автор: Гость

Прочитав эту статью, вы узнаете следующее: способы, которыми можно продлить время жизни временного объекта в С++; рекомендации и подводные камни этого механизма, с которыми может столкнуться С++ прог…
Как мы баг в PVS-Studio искали или 278 Гигабайтов логов

Дата: 28 Окт 2022

Автор: Григорий Семенчев, Сергей Ларин, Филипп Хандельянц

Предлагаем вашему вниманию интересную историю о поиске бага внутри анализатора PVS-Studio. Да, мы тоже допускаем ошибки, но мы готовы засучить рукава и залезть в самую глубину "кроличьей норы".
0, 1, 2, Фредди забрал Blender

Дата: 26 Окт 2022

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

Эта статья могла бы получить название "Как PVS-Studio защищает от поспешных правок кода, пример N7". Однако так именовать статьи становится скучновато. Поэтому сейчас вы узнаете, причём здесь Фредди …
Примеры ошибок, которые может обнаружить PVS-Studio в коде LLVM 15.0

Дата: 25 Окт 2022

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

Компиляторы развиваются и выдают всё больше предупреждений. Остаются ли преимущества от использования статических анализаторов кода, таких как PVS-Studio? Да, так как анализаторы тоже развиваются. Пе…

Комментарии (0)

Следующие комментарии
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо