Звіти про помилки
Оскільки наші розробники не можуть протестувати усі комбінації апаратного забезпечення або кожен спосіб взаємодії з операційною системою, ми покладаємося на користувачів, які можуть надати нам інформацію про те, як система працює на їхньому комп'ютері. Зважаючи на те, що Haiku все ще досить молода, дуже ймовірно, що Ви зіткнетеся з помилками. Ми дякуємо Вам за те, що Ви знайдете час, щоб повідомити про них. Разом ми можемо покращити Haiku, крок за кроком.
Щоб наш багтрекер був ефективним, важливо дотримуватися Етикету (соціальних правил) багтрекера.
Створення облікового запису у системі Trac
Щоб подати тікет, Вам потрібно мати обліковий запис у системі відстеження помилок Haiku.
Створюючи новий обліковий запис, не забудьте вказати свою електронну адресу, оскільки вона необхідна для отримання базових привілеїв на модифікацію тікета. Одразу після цього, не забудьте перевірити папку «Спам», оскільки всі важливі листи з підтвердженням часто потрапляють туди.
Створення звіту про помилку
Перш ніж створити звіт про помилку, будь ласка, переконайтеся, що такий тікет ще не виставлений. Для цього Ви можете скористатися функцією пошуку.
Після того, як Ви переконалися, що це унікальна помилка, зробіть свою інформацію якомога точнішою:
Спробуйте відтворити проблему у поточній редакції Haiku. Тестові образи системи доступні на офіційному сайті.
Надайте основну інформацію, наприклад, як Ви тестуєте Haiku (на реальному обладнанні, на VMWare, на QEMU тощо).
Зазначте, яку ревізію Ви використовуєте. Цю інформацію можна знайти у пункті меню Deskbar. Також зазначте, яку збірку Haiku Ви тестуєте (x86_gcc2, x86_64), яка тестується. Образи, які можна завантажити, мають відповідні назви, для самостійно створеного образу Вам слід знати, як Ви його створили.
Опишіть проблему, з якою Ви зіткнулися. Намагайтеся бути якомога точнішими: опишіть фактичну поведінку та поведінку, яку Ви очікували.
Опишіть, які кроки потрібно виконати, щоб виявити (відтворити) помилку. Це допоможе розробникам відтворити баг.
Додайте якомога більше інформації. Якщо це помилка графічного інтерфейсу або помилка в одній з програм, спробуйте зробити знімок екрана натиснувши клавішу PRINT.
Помилки у програмах
Після аварійного завершення програми Ви можете зберегти звіт про помилку чи записати дамп ядра (обидва зберігаються на Робочому столі), який можна прикріпити при поданні тікета, або викликати Debugger.
Якщо це не збій, Ви можете отримати корисну інформацію під час запуску програми з терміналу. Деякі програми передбачають ведення журналу та інші можливості під час запуску з певними параметрами; спробуйте скористатися командами -h або --help, щоб дізнатися, чи це так. Як приклад, перегляньте різні рівні журналювання у HaikuDepot.
Помилки у серверах
Коли життєво важливі сервери такі як app server, registrar або input server виходять з ладу, Ви не побачите звичного сповіщення про збій. Замість цього весь екран стане білим, відладчик буде запущено у текстовому режимі і його вивід з'явиться безпосередньо на екрані. Скоріш за все, Ви все ще зможете рухати мишею, курсор якої перезапише білий екран і вивід відладчика на екран. Програми, які все ще працюють (наприклад, ProcessController або годинник на панелі задач), також можуть перекривати вивід відладчика на екрані.
Окрім того, що все виглядає більш жахливо і незручно, в основному все те ж саме, що і для помилок у програмі. Найважливіше – зробити зворотне трасування (командою bt). Можливо, Вам доведеться сфотографувати екран цифровою камерою, оскільки скопіювати текст нікуди не вдасться.
Залежно від того, що саме вийшло з ладу, Ви можете спробувати зберегти звіт про помилку на робочому столі за допомогою команди save-report або write-core для дампа ядра, а потім натиснути кнопку живлення один раз, щоб спробувати вимкнути систему повністю. Якщо кнопка живлення не спрацювала, є також команди shutdown і reboot.
Помилки в ядрі
Помилки в ядрі зазвичай мають найсерйозніші наслідки і в той же час їх найважче виправляти. Існують різні типи симптомів, які, найімовірніше, вказують на проблему в ядрі або драйверах:
Система переходить у режим відладки ядра (KDL) за власним бажанням. Верхня частина екрану очищається, стає білою і друкуються кілька рядків тексту. У другому рядку написано "Welcome to Kernel Debugging Land…" а над ним вказано безпосередню причину переходу до режиму KDL.
Спонтанна перезагрузка системи.
Система повністю зависає. Ви не можете рухати мишею і жодна програма більше нічого не малює. Важливим тестом у цій ситуації є перевірка того, чи Ви все ще можете увійти до KDL за допомогою комбінації клавіш ALT SysReq D (SysReq – це PRINT на більшості клавіатур). Зачекайте принаймні хвилину і перевірте, чи нічого не змінилося.
Система загружається неправильно. Вона може спонтанно перезагрузитися або зупинятися на певному етапі (наприклад, на певному значку екрана загрузки). В останньому випадку спробуйте ALT SysReq D.
Уся система або якась її частина поводиться неправильно. Наприклад, вона може працювати дуже повільно, виникають помилки або щось взагалі не працює. Якщо якесь обладнання не працює взагалі, перше, що Ви можете зробити, це перевірити, чи підтримує Haiku його на даний момент (наприклад, запитайте у списку розсилки або на форумі).
Зверніть увагу, що хоча лише останній пункт вказує на апаратну частину, усі інші симптоми можуть бути спричинені помилкою в драйвері обладнання. Якщо у Вас є підозра, що апаратне забезпечення або відповідний драйвер можуть бути пов'язані з проблемою, перевірте, як вплинуло на ситуацію вилучення/вимкнення пристрою або драйвера. Наприклад, якщо Ви підозрюєте Wifi, Ви можете виявити, що у BIOS є можливість вимкнути його. Якщо ні, Ви можете додати відповідний драйвер Wifi до чорного списку встановленої системи Haiku (дивіться розділ Boot Loader).
Kernel Debugging Land – KDL
Якщо система не увійшла у режим KDL самостійно, Ви можете зробити це примусово за допомогою комбінації клавіш ALT SysReq D (SysReq – це PRINT на більшості клавіатур).
Зауважте, що у режимі KDL Ваша клавіатура може не працювати. Клавіатури PS/2 завжди працюють, у випадку з USB-клавіатурами це залежить від типу USB-контролера (UHCI/EHCI). Як правило, клавіатуру слід підключати до порту безпосередньо, а не через хаб. За певних обставин клавіатура може працювати, лише якщо Ви хоча б один раз перейшли у режим KDL за допомогою комбінації клавіш. USB OHCI наразі не підтримується.
Сама KDL є свого роду оболонкою. Можна виконувати команди, які надають інформацію про систему. Можуть бути цікавими наступні команди :
| bt (або sc) | виводить на екран зворотнє трасування (також відоме як перегляд стека). Якщо система увійшла у режим KDL за власним бажанням, зворотне трасування зазвичай виводиться автоматично. Введіть цю команду, якщо цього не сталося або частину трасування не видно (наприклад, якщо трасування стека настільки довге, що воно прокручує екран) і єдиний спосіб надати інформацію розробникам – це зробити знімок екрана. | |
| ints | показує оброблені та необроблені апаратні переривання. | |
| co (або continue) | виходить з відладчика ядра і продовжує нормальну роботу системи, якщо це можливо. | |
| reboot | відразу перезагружає систему. Будуть втрачені усі незбережені дані і навіть ті, які були збережені, але ще не були записані на диск. |
Докладнішу інформацію наведено у статті Welcome to Kernel Debugging Land.
Вивід KDL записується у послідовний порт (якщо у Вас є послідовний порт, відповідний кабель і другий комп'ютер для підключення, Ви можете перехопити вихідні дані за допомогою програми-терміналу) і у файл системного журналу (syslog). Якщо Ви не можете вийти з KDL, дані не будуть записані у файл syslog. Існує опція секції відладки загружчика, яка дозволяє перехоплювати вивод (дивіться нижче).
Ви можете генерувати QR-коди з вихідних даних KDL, які потім можна перетворити на текст за допомогою смартфонів або подібних пристроїв. Про те, як отримати дані з KDL за допомогою цієї функції, дивіться статтю QR Encode your KDL Output.
Системний журнал (Syslog)
Це найкращий спосіб отримати інформацію з системи, яка не загружається.
Syslog (скорочення від system log – системний журнал) містить цінну інформацію про те, що сталося у Вашій системі, зокрема виведення відладочної інформації сеансів KDL. Зазвичай рекомендується долучати його до пов'язаного з ядром тікета системи Trac. Системний журнал записується у файл /boot/system/var/log/syslog. Оскільки для запису у файл потрібна робоча система, при виникненні проблем ядра (зокрема, під час спонтанних перезагрузок або перериванні сеансів KDL), крайній вивід міг не потрапити до системного журналу.
Опція меню загружчика вмикає запис системного журналу на постійній основі. Якщо у параметрах відладки загружчика увімкнено опцію (увімкнена за замовчуванням), системний журнал Вашого останнього сеансу запишеться як файл /boot/system/var/log/previous_syslog.
Якщо Ви не можете загрузитися, щоб отримати доступ до «previous_syslog», Вам потрібно увійти у меню загружчика, утримуючи клавішу SHIFT під час загрузки (або SPACE для загрузки через UEFI).
У меню загружчика Ви знайдете опції і . Перша опція виводить syslog на екран, друга дозволяє зберегти його у вигляді файлу на диск. Зверніть увагу, що на даний момент для збереження файлу підтримуються лише томи FAT32. Якщо Ви хочете використати USB-накопичувач, але підключили його занадто пізно і він ще не розпізнаний, Ви можете перезагрузити комп'ютер і знову увійти до меню загружчика. Примітка: Не загрузіть випадково будь-яку іншу операційну систему, інакше дані буде втрачено.
Виведення відладочної інформації на екран
Виведення відладочної інформації на екран корисне лише для виправлення дуже специфічних проблем і, як відомо, має проблеми з синхронізацією. Не використовуйте його без необхідності.
Це стосується лише тих випадків, коли Haiku не вдається загрузитися на Вашому комп'ютері, а опція з якихось причин не спрацьовує. Перш ніж з'явиться логотип завантаження Haiku, утримуйте клавішу SHIFT (або SPACE для загрузки через UEFI), щоб увійти у меню загружчика. Далі, зайдіть у меню . Там Ви знайдете опцію . (Примітка: Під час спроби загрузки Haiku можуть бути увімкнені інші опції. Якщо Haiku загружається лише після увімкнення одної або кількох опції, обов'язково вкажіть їх).
Нарешті, виберіть , а потім .
На екрані з'явиться одна або кілька сторінок тексту, лише останні кілька рядків потрібно включити у Ваш тікет. Більше інформації про загружчик можна знайти у розділі Boot Loader.
Помилки в апаратному забезпеченні/драйверах
Якщо Ви маєте справу з помилкою, пов'язаною з апаратним забезпеченням/драйвером, Вам слід прикріпити до тікета наступну інформацію у вигляді текстових файлів:
| – listdev | детальний список Вашого обладнання, включно з ідентифікаторами виробника та pci, подібно до команд lshw та lspci у Linux. | |
| – listusb -v | детальна інформація по USB, припускаємо, що проблема може бути пов'язана з USB, команда аналогічна lsusb. | |
| – open /var/log/syslog | основний системний журнал, який використовує Haiku, дивіться вище Системний журнал, який схожий на екранний вивід відладчика під час завантаження. За допомогою команди open Ви можете вирізати відповідну частину системного журналу у текстовому редакторі. | |
| – listimage | grep drivers/ | список усіх використаних драйверів. | |
| – usb_hid_report | у разі використання USB-пристроїв додайте файл /tmp/usb_hid_report_descriptor_*.bin. | |
| – ints | Доступно лише у режимі Kernel Debugging Land (дивіться вище). Показує використання переривань. Не повинно бути занадто багато переривань, які спільно використовуються різними пристроями. | |
| – Вивід відладочної інформації на екран (опція меню вибору параметрів відладки загружчика, дивіться вище). | ||
Перші чотири команди вводяться у терміналі. Додайте « > output.txt» після команди і вона буде збережена у текстовому файлі з назвою «output.txt», який Ви можете прикріпити до Вашого звіту про помилку або електронного листа.
І що далі?
Після створення звіту про помилку розробник розгляне її та спробує класифікувати. Пам’ятайте, що ми всі волонтери і тому інколи звіт про помилку може деякий час залишатися без відповіді. Додавання нової інформації до звіту, коли вона стає доступною, зазвичай допомагає швидше виправити помилку, але не намагайтеся «підняти» звіт додаванням неінформативних коментарів.
Пам’ятайте, що створення звіту про помилку – це не те, на що Ви витратите трохи часу і цим усе закінчиться. Якщо Ви створюєте звіт про помилку, Ви берете участь у процесі розробки Haiku. У розробників можуть виникнути запитання, коли вони намагаються виправити помилку. Будь ласка, залишайтеся на зв'язку, щоб відповісти на них. Вважайте свою участь «завершеною», коли помилка буде позначена як «виправлена» а звіт про помилку закритий.