Reportando erros
Uma vez que nossos desenvolvedores não são capazes de testar todas as combinações de hardware nem todas as diferentes formas de interação com o sistema operacional, nós contamos com os usuários para dar-nos algum retorno sobre como as coisas funcionam em seu equipamento. Uma vez que o Haiku é ainda um tanto jovem, é muito provável que irá encontrar erros. Agradecemos por dispor de tempo para reportá-los. Juntos melhoraremos o Haiku, bit a bit.
Para manter nosso rastreador de erros eficaz, é essencial obedecer à Etiqueta do Rastreador de Erros.
Obtendo uma conta do Trac
Para arquivar um tíquete, é necessária uma conta no Rastreador de Erros do Haiku.
Ao criar uma nova conta, certifique-se de informar seu endereço de correio eletrônico, necessário para obter privilégios básicos para modificação do tíquete. Assegure-se de verificar sua pasta de correspondência indesejada logo depois, afinal toda verificação de correios importantes costuma acabar aí.
Criando um relatório de erro
Antes de reportar um erro, por favor certifique-se de que ele ainda não existe. Pode-se também utilizar a função de pesquisa para isso.
Após constatar que é um erro original, torne sua informação a mais acurada possível:
Tente reproduzir o problema na versão atual do Haiku. Imagens pré-compiladas para o propósito de testes estão disponíveis.
Inclua informação básica sobre como está testando o Haiku (em equipamento real, no VMWare, no QEMU, etc.).
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.
Descreva o problema que está experimentando. Tente ser o mais acurado possível: descreva o comportamento atual e o comportamento que deseja.
Descreva que passos precisa realizar a fim de expor o erro. Isto ajudará os desenvolvedores a reproduzir o erro.
Anexe toda a informação que tiver. Se é um erro de interface gráfica, ou um erro em um dos aplicativos, tente obter uma imagem da tela pressionando a tecla PRINT.
Erros de Aplicativo
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.
If it's not a crashing bug, you may get useful information when starting the application from Terminal. Some applications provide logging and other options when started with certain parameters; try -h or --help to see if that is the case. As example, see the different logging levels of HaikuDepot.
Erros de servidor
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.
Erros do Kernel
Erros de Kernel são sempre os únicos com os efeitos mais graves e ao mesmo tempo os mais difíceis de depurar. Existem diferentes tipos de sintomas, os quais mais provavelmente apontam um problema de kernel ou de driver:
O sistema aciona a Terra da Depuração do Kernel (KDL) por si mesmo. A parte superior da tela torna-se branca e várias linhas de texto são mostradas. A segunda linha diz "Bem vindo a Terra da Depuração do Kernel...", a linha acima dela afirma a razão imediata para entrar na KDL.
O sistema reinicia espontaneamente.
O sistema congela completamente. Não se pode mover o mouse e nenhum aplicativo faz nada mais. Um importante teste naquela situação é, se ainda puder entrar na KDL pelo atalho ALT SysReq D (SysReq sendo PRINT na maioria dos teclados). Aguarde ao menos um minuto para ver se algo acontece.
O sistema não inicializa corretamente. Ele pode reiniciar espontaneamente ou pára em algum ponto (por exemplo, em algum ícone da tela de inicialização). No último caso tente também ALT SysReq D.
O sistema inteiro ou alguma parte do equipamento não se comporta corretamente. Por exemplo, ele pode ficar muito lento, ocorrerem erros ou algo não funcionar absolutamente, a primeira verificação óbvia é se o Haiku já o suporta completamente (por exemplo, perguntando em uma lista de discussão ou num fórum).
Observe que enquanto o último ponto parece indicar uma relação com hardware, todos os outros sintomas podem ser causados também por um erro num driver de dispositivo. Caso tenha uma suspeita de que parte do hardware ou o driver correspondente pode ter algo a ver com o problema, verifique se removendo/desabilitando o dispositivo ou o driver faz alguma diferença. Por exemplo, se há suspeita sobre o Wifi, pode-se procurar na BIOS uma opção para desabilitá-lo. Ou se não, pode remover o driver Wifi responsável a partir da sua instalação do Haiku (em /boot/system/add-ons/kernel/drivers/bin).
Terra da Depuração do Kernel - 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.
O KDL propriamente é uma espécie de shell. Alguém pode executar comandos que exibem informação sobre o sistema. Os seguintes comandos podem ser de interesse:
| 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 | Mostra as interrupções de dispositivos tratadas e não tratadas. | |
| co (conhecido como continue) | Sai do depurador do kernel e continua a operação normal do sistema, se for possível. | |
| reboot | Reinicia o sistema imediatamente. Perder-se-á todos os dados não salvos e até mesmo aqueles que tenham sido salvos, mas que não tenham sido gravados no disco. |
Para mais informações, veja o artigo Bem vindo à Terra da Depuração do Kernel.
A saída do KDL é enviada para uma porta serial (caso tenha um, um cabo respectivo e um segundo computador conectado a ele, pode-se capturar a saída lá através de um programa de terminal) e para o relatório do sistema. Entretanto, se não puder sair do KDL ela não será escrita no arquivo de relatório do sistema. Todavia, existe uma opção de depuração do carregador da inicialização que permite capturá-la (veja abaixo).
Pode-se gerar códigos QR a partir da saída do KDL que pode então ser convertido para texto utilizando smartphones ou dispositivos similares. Veja a postagem de blog QR codifica sua saída do KDL sobre como obter saída de dados do KDL utilizando aquela funcionalidade.
Relatório de sistema
Este é o método preferido para obter informação de um sistema que não inicializa.
O relatório do sistema contém informação valiosa sobre o que aconteceu no seu sistema, incluindo a saída das sessões da KDL. É geralmente uma boa ideia anexá-lo ao tíquete do Trac relacionado ao kernel. O relatório do sistema é gravado no arquivo /boot/common/var/log/syslog. Uma vez que gravar um arquivo requer um sistema funcional, a saída mais recente deve não ter sido feita ao relatório de sistema quando um problema de kernel ocorre (particularmente em reinicializações espontâneas ou sessões descontinuadas da KDL).
The option in the boot loader's makes the syslog persistent. If the option is activated in the boot loader options (as it is by default), you'll find the syslog of your last session as /boot/system/var/log/previous_syslog.
If you're not able to boot to get to the previous_syslog, you have to enter the boot loader menu by holding down SHIFT (or SPACE when booting via UEFI) while booting.
In the boot loader's you should find the entries and . The former displays the syslog on screen, the latter allows you to save it as a file to disk. Note that at the moment only FAT32 volumes are supported for saving the file. If you want to use a USB stick, but have plugged it in too late so that it isn't recognized yet, you can reset the machine and re-enter the boot loader menu. Note: Don't accidentally boot any operating system or the data will be lost.
Saída de depuração na tela
The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.
This is only relevant when Haiku fails to boot on your machine and the option doesn't work for some reason. Before the Haiku boot logo appears, hold SHIFT (or SPACE when booting via UEFI) to enter the boot loader menu. Select . Near the bottom, will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)
Finally select and then .
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the Boot Loader.
Erros de Dispositivo/Driver
Enquanto estiver lidando com um erro relativo a dispositivo/driver, deve-se anexar as seguintes informações como arquivos de texto:
| - listdev | Uma lista detalhada do seu dispositivo, incluindo fornecedor e id's pci, similar ao lshw e lspci do Linux. | |
| - listusb -v | Supondo que seja um problema relacionado a USB, é similar ao 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/ | Lista todos os drivers utilizados. | |
| - usb_hid_report | In case of USB input devices, add the /tmp/usb_hid_report_descriptor_*.bin file. | |
| - ints | Apenas disponível na Terra da Deupração do Kernel (ver acima). Exibe a utilização das interrupções. There shouldn't be too many that are shared by different devices. | |
| - On screen debug output (a debug boot time option, see above). | ||
Os primeiros quatro comandos são executados no Terminal. Adicione um > output.txt após um comando e ele será direcionado para um arquivo de texto chamado "output.txt" que pode ser anexado a seu relatório de erro ou mensagem de correio eletrônico.
O que vem a seguir?
Após o erro ter sido reportado, um desenvolvedor irá dar uma olhada e tentar classificá-lo. Lembre-se, nós somos voluntários e, como tais, algumas vezes um relatório de erro pode ficar sem resposta por um tempo. Adicionar informação nova quando disponível geralmente ajuda a selecionar o problema mais rapidamente, mas não tente 'incrementar' o erro adicionando comentários não descritivos.
Lembre-se, reportar um erro não é algo a que se dispensa um pouco de tempo e então está resolvido. Se reportou um erro, então você é parte do processo de desenvolvimento do Haiku. Desenvolvedores podem aparecer com perguntas enquanto eles estão tentando consertar o erro. Por favor esteja disponível para respondê-los. Considere sua participação 'terminada' quando o erro estiver marcado como 'corrigido'.