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

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

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

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

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

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

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


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

>
>
Пять дней на исправление ошибки в два с…

Пять дней на исправление ошибки в два символа, или миф о всемогущих технологиях при разработке программ

30 Авг 2010

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

Однажды после выпуска новой версии статического анализатора кода 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 скрипта. Поэтому повторить ошибку не удавалось довольно долго.

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

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

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

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

Опрос:

Популярные статьи по теме
Как Apple и другие крупные компании настиг программный баг

Дата: 09 Ноя 2022

Автор: Ульяна Гришина

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

Дата: 30 Авг 2022

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

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

Дата: 26 Май 2022

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

Анализатор PVS-Studio умеет "схлопывать" повторяющиеся предупреждения. Предоставляет возможность задать baseline, что позволяет легко внедрять статический анализ в legacy-проекты. Стоит ли предостави…
15000 ошибок в открытых проектах

Дата: 24 Май 2022

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

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

Дата: 04 Май 2022

Автор: Сергей Хренов

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

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

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