Для відстеження статусу замовлення - авторизуйтесь
Введіть код, який був надісланий на пошту Введіть код із SMS, який був надісланий на номер
 
Код дійсний протягом 2 хвилин Код з SMS дійсний протягом 2 хвилин
Ви впевнені, що хочете вийти?
Сеанс завершено
На головну
Чому з’являються гейзенбаги та як із ними працювати

Чому з’являються гейзенбаги та як із ними працювати

Що таке плавучий баг.

Тестувальник зафіксував у програмі помилку, а ось повторити її не вдається. Отже, трапився плавучий баг — його треба знайти, спіймати та перетворити на звичайний. Але зробити це буває складно.

Розповідаємо, що треба знати про гейзенбаг та як його виправити.

Що таке гейзенбаг
 

Гейзенбаг (плавучий баг) — це небажані дії програми, що виникають спонтанно. Такі баги шукають QA-фахівці. Алгоритмів, які автоматично визначають плавучі баги, немає.

Термін названо на честь фізика Вернера Гейзенберга. Він сформулював принцип невизначеності у квантовій фізиці.

Причини появи плавучого бага

  • Час

Якщо під час дебагінгу фахівці виконують інструкцію по рядках, то затримка між операціями може бути на кілька порядків більша, ніж під час роботи продукту. Особливо це актуально, якщо гейзенбаг спричинений взаємодією різних потоків.

  • Пам’ять

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

  • Assert

У продакшені або щоразу, коли код компілюється з активованими параметрами оптимізації, асерти зазвичай відключені, тоді як під час локальної компіляції в режимі розробки вони можуть бути активними. Оцінювання тверджень може мати побічні ефекти або просто впливати на час виконання.

  • Переповнення

Тестувальник може не звернути увагу на те, що поле або контейнер переповнені, і це спровокувало збій у роботі. Система не може впоратися, якщо в неї всередині обчислюються величезні значення.

  • Рандомізація

Якщо в коді є рандомізація, це також може спричинити невідповідності між різними прогонами, і можуть періодично з’являтися потрібні умови для виникнення помилки.

Як розв’язати проблему з плавучим багом
 

Універсального рішення немає, але є техніки, які здатні допомогти:

  • Моніторинг системних процесів

Важливо, щоби жоден інший процес не заважав основному.

  • Запуск на CPU замість GPU. Графічний процесор дає приріст продуктивності, але програмне забезпечення за умовчанням може його не підтримувати. Вимкніть графічний процесор у своїй системі та спробуйте запустити його на CPU.
     
  • Перевірка коду на наявність генераторів випадкових чисел. Потрібно протестувати його, знаходячи генератори випадкових чисел і відстежити випадковий вивід для вдалих і помилкових прогонів.
     
  • Запуск на одному вузлі NUMA гарантує, що плавучий баг виник не через проблеми з архітектурою системи. Між вузлами NUMA часто спостерігається нестабільність з’єднань.
     
  • Зміна залежності ПЗ. Важливо, щоби гейзенбаг не походив від зовнішнього програмного компонента. Наприклад, замість використання TensorFlow, оптимізованого для Intel з DNNLv1.1, можна спробувати Vanilla TensorFlow (створений із вихідних кодів або встановлений за допомогою pip).
     
  • Видалення зайвих функцій по черзі дасть з’ясувати, яка з них — джерело плавучого бага.
     
  • Запуск стрес-тестів допоможе виявити потенційні помилки в екстремальних умовах. Але тестування не доводить відсутність помилок. Стрес-тести лише дають змогу знизити ризик непомічених помилок у робочому середовищі.
     
  • Використання спеціальних алгоритмів виявлення потенційного стану гонки (Race condition). Алгоритм набору блокувань повідомляє про потенційний стан гонки, коли до загальної пам’яті звертаються два або більше потоків, що утримують загальне блокування. Він може повідомляти про помилкові спрацьовування. Алгоритм «відбувається до» ґрунтується на частковому упорядкуванні подій (за будь-якої інструкції, включно з читанням/записом та блокуванням) у розподілених системах всередині та між потоками. Цей алгоритм генерує дуже мало помилкових спрацьовувань, але він чутливий до порядку виконання, тому може знадобитися запустити його кілька разів, перш ніж вдасться виявити стан гонки, що викликає плавучий баг.

  • Зворотний дебагінг — здатність дебагера зупинятися після збою в програмі та повертатися до історії виконання, щоби розкрити причину збою.
     
  • Використання спеціальних інструментів дебагінгу для стану гонки. Ось кілька прикладів:

#1. Microsoft CHESS — інструмент для пошуку та відтворення гейзенбага в паралельних програмах. CHESS багаторазово запускає паралельний тест. Якщо чергування призводить до помилки, CHESS може відтворити його для покращення дебагінгу.

#2. The Intel Inspector допомагає знаходити та налагоджувати помилки потокової передачі, пам’яті та постійної пам’яті на ранніх етапах циклу проєктування.

#3. Kiuwan — інструмент статичного аналізу коду. Він виявляє загрози безпеці до того, як вони потраплять у робоче середовище.

#4. RacerX використовує чутливий до потоку міжпроцедурний аналіз для виявлення як стану гонки, так і взаємоблокувань.

  • Використання інструментів дебагінгу:

C ++: UDB. Знаходить та виправляє помилки. 

C #: RevDeBug. Виправляє помилки під час діагностики збоїв програмного забезпечення. 

Python: RevPDB. Дає змогу переміщатися вперед та назад.

Ще статті
Експертки про те, як оцінюють кандидатів на нетехнічних інтерв’ю
Частина 2. Робота із записами: вставка, читання, змінення й видалення