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

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

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

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

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

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

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


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

Баги

15 Апр 2013

Баги (Bugs) – это жаргонное название программной ошибки. Ошибкой можно назвать любое недокументированное поведение программы. Однако багами принято называть ошибки, обнаруженные уже на этапе выполнения программы, а не на этапах проектирования, кодирования или отладки.

История возникновения этого термина связана с испытаниями вычислительной машины 'Mark II' 9 сентября 1947 года, когда между контактов электромеханического реле попал мотылек. Извлеченное насекомое было вклеено в технический дневник и рядом сделана надпись "First actual case of bug being found".

Баги могут возникать непосредственно при программировании или из-за ошибок компиляторов. Так же ошибки могут оказаться не в вашем коде, а в сторонних библиотеках, используемых приложением. Случаются ошибки и из-за неправильного использования библиотек. Ошибки компиляторов чаще всего возникают из-за некорректной оптимизации различных конструкций языка программирования. Впрочем, это крайне редкие случаи. Как правило, те ошибки, в которых программист винит компилятор, при детальном рассмотрении оказываются его собственными ошибками (см. заметку "Во всём виноват компилятор").

Чаще всего, для поиска места в коде, где находится баг, используются специальные утилиты - отладки программ (жаргонное название – дебагеры). Они позволяют посмотреть значения переменных, регистров процессора и другие параметры, влияющие на ход выполнения программы и многие другие необходимые параметры. Есть и другие способы, такие как статический или динамический анализ.

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

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

Программные ошибки могут привести к многомилионным потерям или человеческим жертвам. Этому есть много примеров. Так запуск ракеты-носителя "Ариан 5" закончился взрывом. Причиной этому послужило несколько факторов: использование модуля навигационной системы от "Ариан 4", который не был рассчитан на входные значения перегрузки, возникшие при запуске. В навигационной системе использовался программный модуль, выполнявший перевод значений с плавающей точкой в целочисленный 16-битный формат. Именно там и возникло переполнение переменной. Свою роль и сыграло требование на 80% максимальную загрузку процессора, из-за которой были исключены из проверки на возможное переполнение переменные, ставшие причиной переполнения. Самое парадоксальное, что вызвавший отказ модуль уже был не нужен. Данные от него требовались в течение первых 7 секунд полета и это время они были корректны. Авария из-за переполнения случилась на 37 секунде.

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

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

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

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

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

Популярные статьи по теме
Обрабатывать ли в PVS-Studio вывод других инструментов?

Дата: 26 Май 2022

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

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

Дата: 24 Май 2022

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

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

Дата: 04 Май 2022

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

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

Дата: 15 Фев 2022

Автор: Николай Миронов

Кажется, анонс Visual Studio 2022 был только недавно, и вот она уже вышла. Это означало ровно одно – поддержать данную IDE нужно в ближайшем релизе PVS-Studio. О том, с какими сложностями пришлось ст…
Лучшие срабатывания статического анализатора

Дата: 29 Окт 2021

Автор: Максим Звягинцев

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

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

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