Українська
Català
Deutsch
English
Español
Français
Italiano
Magyar
Polski
Português
Português (Brazil)
Română
Slovenčina
Suomi
Svenska
中文 ［中文］
Русский
日本語Зголошення про помилки
Так як наші розробники не можуть протестувати всі комбінації апаратного забезпечення, ні дуже різні способи їх взаємодії з операційною системою, ми покладаємося на користувачів щоб отримати деякі матеріали про роботу їхнього "заліза" в решті решт. Так як Haiku все ще досить молода, дуже ймовірно, що Ви будете мати справу з помилками. Ми дякуємо Вам за те що Ви знайшли час щоб повідомляти про них. Разом ми поступово зможемо поліпшити Haiku.
Для збереження ефективності багтрекера, дуже важливо підтримувати етикет Зголошення про помилки (Bug Tracker).
Створення облікового запису у Trac
Щоб подати квиток, вам потрібно створити обліковий запис на сторінці Зголошення про помилки Haiku.
При створенні нового облікового запису обов'язково подайте Вашу електронну адресу бо це необхідно, щоб отримати основні привілеї модифікації квитків. Обов'язково перевірте Вашу спам-теку одразу після цього, позаяк усі важливі перевірки листів закінчуються переважно там.
Створення звіту про помилку
Перед тим, як повідомити про помилку, будь ласка переконайтесь що вона ще не існує. Ви також можете використати для цього функцію пошуку.
Після того як Ви встановили що це унікальна помилка постарайтесь зробити інформацію про неї якомога точнішою:
Спробуйте відтворити проблему на поточній версії Haiku. Передналаштовані образи для цілей тестування доступні в інтернеті.
Повідомте основну інформацію про те як Ви тестуєте Haiku (на реальному залізі, у VMWare, у QEMU і тд).
Mention which revision you are running. You can find this information in from the Deskbar menu. Also mention what kind of Haiku build you are testing (x86_gcc2, x86_64). The downloadable images are named accordingly, for a self-built image you should know how you built it.
Опишіть проблему яка Вас спіткала. Постарайтесь бути якомога точнішим: опишіть реальну поведінку та ту яку Ви очікуєте.
Опишіть які кроки необхідно виконати для того, щоб натрапити на помилку. Це допоможе розробникам відтворити її.
Вкладіть всю інформацію яка у Вас є. Якщо це помилка графічного інтерфейсу або помилка одного з додатків спробуйте при можливості зробити знімок екрану натиснувши клавішу PRINT.
Помилки у додатках
When an application crashed, you can either save a report or write a core file (both saved to the Desktop) that you can attach to a bugreport, or you can evoke the Debugger.
Помилки у серверах
When vital servers like the app server, the registrar or the input server crash, you won't see the usual crash alert. Instead the whole screen will be cleared white and the Debugger will be started in text-mode, its output appearing directly on screen. Likely you will still be able to move the mouse, which will overwrite the white and Debugger output on screen. Applications still running (like ProcessController or the clock in the Deskbar) might also draw over the debugger output on screen.
Besides everything being more ugly and inconvenient, basically the same applies as for application bugs. Most importantly procure a back trace (bt command). You may need to take a picture of the screen with a digital camera, since you won't be able to copy the text anywhere.
Depending on what exactly crashed, you can try to save a crash report on the Desktop with save-report or write-core for a core file, and then press the power button once to try shutting cleanly down. If the power button doesn't work, there are also the commands shutdown and reboot.
Помилки у ядрі
Помилки ядра звичайно мають найтяжчі наслідки і у то же час дуже важко підаються відладці. Існують різні види симптомів, які, швидше за все, вказують на проблеми ядра або драйвера:
Система переходить в режим відладки ядра (KDL) за власною волею. Верхня частині екрану очищається, стає білою і друкуються кілька рядків тексту. Другий рядок говорить: "Ласкаво просимо на територію відладки ядра... (Welcome to Kernel Debugging Land...)", рядком вище говориться про те що власне стало причиною введення режиму KDL.
Система перевантажується мимовільно.
Система повністю замерзає. Ви не можете переміщати мишку, жоден додаток не працює. Важливим тестом є у цій ситуації спроба викликати KDL за допомогою комбінації ALT SysReq D (SysReq буде PRINT на більшості клавіатур). Зачекайте хоча б хвилину, щоб побачити, чи буде що-небудь відбуватися.
Система не завантажується правильно. Вона може спонтанно перезавантажитися або зупинитися у якийсь момент (наприклад, на якійсь іконці екрану завантаження). В останньому випадку також варто спробувати ALT SysReq D.
Вся система або будь-яка частина обладнання поводиться неправильно. Наприклад, все дуже сповільнено, виникають помилки або щось не працює взагалі. Якщо якесь обладнання не працює взагалі, перша очевидна перевірка, чи підтримує Haiku його взагалі на даний момент взагалі (наприклад запитати в списку розсилки або на форумі).
Зверніть увагу, що хоча останній пункт і вказує на апаратну проблему всі інші симптоми можуть бути викликані помилкою в драйвері. Якщо у вас є підозра, що частина апаратних засобів або відповідного драйвера, можливо, мають відношення до проблеми, перевірте чи видалення / відключення апаратного забезпечення або драйвера викликає зміни. Наприклад, при підозрі на Wi-Fi може виявитись, що ваш BIOS дає можливість відключити його. Або, якщо не має, то ви могли би додати у чорний список відповідний драйвер Wi-Fi встановленої Вами Haiku (дивись Завантажувач системи (Boot Loader)).
Територія відладки ядра (Kernel Debugging Land) - далі KDL
If the system hasn't entered KDL by itself, you can do that intentionally by invoking the keyboard shortcut ALT SysReq D (SysReq being the Print key, normally).
Note that in KDL your keyboard may not work. PS/2 keyboards always do, with USB keyboards it depends on the type of USB controller (UHCI/EHCI). Generally, the keyboard should be plugged into the port directly, not via any hubs. In some circumstances, the keyboard only works if one has entered KDL via the keyboard shortcut at least once. USB OHCI is not supported at the moment.
Сама KDL є свого роду оболонкою. Можна виконувати команди, які надають інформацію про систему. Можуть бути цікавими наступні команди :
| bt (aka sc) | Prints a back trace (aka stack crawl). If the system entered KDL on its on volition, a back trace is normally printed automatically. Enter the command if that didn't happen or part of it is obscured (e.g. when the stack trace is so long that it wrapped around) and your only way of providing the information to developers is by taking a picture of the screen. | |
| ints | показати оброблені та необроблені переривання апаратного забезпечення. | |
| co (aka continue) | залишити територію відладки ядра та продовжити при можливості роботу системи. | |
| reboot | негайно перезавантажує систему. Будуть втрачені всі незбережені дані і навіть ті, які були збережені, але ще не були записані назад на диск. |
Для детальнішої інформації дивіться статтю Вітаємо на території відладки ядра (Welcome to Kernel Debugging Land).
Вихід KDL записується в послідовний порт (якщо у Вашому комп'ютері є такий порт, Ви маєте відповідний кабель та інший комп'ютер, щоб з'єднатися з Вашим, то зможете захопити вихід звідти через термінальну програму) і в системний журнал. Якщо ви не можете залишити KDL він не буде записуватися в файл системного журналу, проте, в налаштуваннях завантажувача є опція, що дозволяє захопити його. (див нижче).
Ви можете генерувати QR-коди з виходу KDL, які потім є можливість перетворити в текст за допомогою смартфонів або аналогічних пристроїв. Дивіться в блозі QR розшифровує вивід KDL про те, як отримати дані з KDL за допомогою цієї функції.
Системний журнал (Syslog)
Це найкращий спосіб отримати інформацію з системи, що не може завантажитись.
Системний журнал (syslog) містить цінну інформацію про те, що сталося у вашій системі, в тому числі вивід сесій KDL. Я правило буде хорошою ідеєю прикріпити її до квитка Trac що описує помилку в ядрі. Системний журнал записується у файл /boot/system/var/log/syslog. Оскільки запис в файл вимагає робочу систему, при помилці у ядрі остання сесія не може бути записана (особливо при спонтанному перезавантаженні або перерваній сесії KDL).
Опція у вікні Завантажувача системи зробить системний журнал стійкішим. Якщо опція активована (це типове налаштування Завантажувача системи), Ви знайдете системний журнал Вашої останньої сесії як /boot/system/var/log/previous_syslog.
Якщо ви не в змозі завантажитись, щоб дістатися до системного журналу попередньої сесії, ви повинні увійти в меню завантажувача, утримуючи клавішу SHIFT при завантаженні.
У пункті Завантажувача системи Ви знайдете записи та . Перший покаже syslog на екрані, другий дозволить зберегти журнал на диск. Зверніть увагу, що на даний момент підтримуються для збереження файлу тільки томи з файловою системою FAT32. Якщо ви хочете використовувати USB флешку, але підключили її занадто пізно, вона може не розпізнатись, спробуйте перезавантажити машину та знову увійти в меню завантажувача. Примітка: випадково не завантажте будь-яку операційну систему, бо дані системного журналу будуть втрачені.
Вивід відладки на екран
Вивід відладки на екран буде корисним тільки для відладки дуже специфічних і як відомо має проблеми з синхронізацією. Не використовуйте його якщо це Вам конче не необхідно.
Таке актуально лише тоді коли Haiku не завантажується на Вашому комп'ютері і по якійсь причині пункт меню не працює. Перед появою лого завантаження Haiku натисніть та утримуйте клавішу SHIFT для того щоб увійти до меню завантажувача. Виберіть пункт . Нижче буде вказано . (Зауваження: Інші опції будуть увімкнені при спробі завантажити Haiku. Якщо вона буде завантажуватись тільки при активації одної або кількох опцій, вкажіть які з них включені.)
Нарешті виберіть а тоді .
На екрані відобразяться одна або кілька сторінок тексту, тільки останніх декілька рядків повинні бути включені до квитка. Більше інформації тут Завантажувач системи (Boot Loader).
Помилки драйверів апаратного забезпечення
Коли ми маємо справу з помилкою пов'язаною з драйвером апаратного забезпечення, необхідно додати наступну інформацію у вигляді текстових файлів:
| - listdev | детальний список Вашого апаратного забезпечення, включаючи визначники vendor id та pci id, аналогічно Linux'овим командам lshw та lspci. | |
| - listusb -v | підсумок всього що зв'язане з USB, аналогічно lsusb. | |
| - open /var/log/syslog | The primary system log used by Haiku, see Syslog above, akin to on screen debugging during boot. With the open command you can crop down the relevant part of the syslog in a text editor. | |
| - listimage | grep drivers/ | перелічує всі драйвери які використовуються. | |
| - ints | Доступне тільки зсередини Території відладки ядра (Kernel Debugging Land) (дивись вище). Показує використання переривань. Не повинно бути занадто багато таких, які спільно використовують різні пристрої. | |
| - On screen debug output (a safe mode boot time option, see above). | ||
Перші чотири команди вводяться в Терміналі. Додайте > output.txt після команди, і це конвеєрує вивід в текстовий файл з ім'ям "output.txt", який ви можете прикріпити до зголошення про помилку або до електронного листа.
Що далі?
Після зголошення про помилку розробники вивчають її та пробують класифікувати. Пам'ятайте, ми всі добровольці тому зголошення певний час залишатиметься без відповіді. Додавання нової інформації, коли вона стає доступною, як правило, допомагає розв'язати помилку швидше, але не намагайтеся торпедувати її, додаючи нерозшифровувані коментарі.
Пам'ятайте, повідомлення про помилку не те, що ви витратити трохи часу на нього, та потім зробили. Якщо Ви повідомили про помилку, то стаєте частиною процесу розробки Haiku. Розробники можуть звернутися з запитаннями при намаганні виправити помилку. Будь ласка, залишайтеся поруч, щоб відповісти на них. Розглянемо Вашу участь у "Готово", коли помилка буде позначена як "пофіксена".