Tu peux toujours commencer par remonter le problème à ta distribution. Si tu arrives à reproduire le problème avec la dernière version upstream fraichement compilée sans patch tiers, il peut être utile de remonter le problème chez eux aussi mais le mainteneur du paquet dans ta distro devrait le faire de toute façon.
Ta distro dispose sans doute d'instructions expliquant quelles informations remonter quand tu ouvres un bug. La documentation du paquet lui même dispose peut-être aussi de ce genre d'instructions. J'ai cherché aucune des ces instructions, ce qui suit vient juste d'idées qui m'ont traversées l'esprit en lisant ton message.
$ uname -a
$ dmesg --version
$ env # surtout $TERM en fait
Vois si tu arrives à contourner le problème en utilisant diverses combinaisons des options de dmesg et en variant certains paramètres de l'environement (au sens général, pas au sens variables d'env). Que tu y arrives ou pas, l'information peut être utile à mettre dans le rapport de bug. Par exemple, est-ce que --clear fonctionne et est-ce que le problème persiste après ? Est-ce que le problème persiste après un reboot ? Est-ce que tu peux reproduire le problème avec différents shells, émulateurs de terminal et kernels ? Si c'était du x86 je suggèrerais de reproduire le problème avec Valgrind ou ElectricFence. Il existe sans doute des équivalents pour ARM que tu peux essayer.
Si ta distribution fourni les symboles de debug (debuginfo) pour le paquet correspondant, essaie de relancer gdb après les avoir installés.
Si ta distribution ne fourni pas les symboles de debug, tu peux recompiler le paquet avec CFLAGS+=-ggdb et ainsi récupérer un backtrace ou core plus informatif.
Si le problème est lié au contenu du ring buffer, tu peux tenter de le récupérer indépendamment avec un debugger noyau (crash(8) a une commande "dmesg" interne mais je suis sûr qu'il y en a d'autres).
Si les symboles de debugs ne sont pas disponibles et que recompiler n'est pas pratique, tu peux désassembler la fonction qui merde ("disass" dans gdb ou just objdump -D sur le binaire) et tenter de comprendre le problème comme ça. Avoir le code source correspondant sous les yeux aide beaucoup.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# rebuild avec -ggdb
Posté par Krunch (courriel, site web personnel) . En réponse au message Où poster ce bug et comment?. Évalué à 2.
Tu peux toujours commencer par remonter le problème à ta distribution. Si tu arrives à reproduire le problème avec la dernière version upstream fraichement compilée sans patch tiers, il peut être utile de remonter le problème chez eux aussi mais le mainteneur du paquet dans ta distro devrait le faire de toute façon.
Ta distro dispose sans doute d'instructions expliquant quelles informations remonter quand tu ouvres un bug. La documentation du paquet lui même dispose peut-être aussi de ce genre d'instructions. J'ai cherché aucune des ces instructions, ce qui suit vient juste d'idées qui m'ont traversées l'esprit en lisant ton message.
$ uname -a
$ dmesg --version
$ env # surtout $TERM en fait
Vois si tu arrives à contourner le problème en utilisant diverses combinaisons des options de dmesg et en variant certains paramètres de l'environement (au sens général, pas au sens variables d'env). Que tu y arrives ou pas, l'information peut être utile à mettre dans le rapport de bug. Par exemple, est-ce que --clear fonctionne et est-ce que le problème persiste après ? Est-ce que le problème persiste après un reboot ? Est-ce que tu peux reproduire le problème avec différents shells, émulateurs de terminal et kernels ? Si c'était du x86 je suggèrerais de reproduire le problème avec Valgrind ou ElectricFence. Il existe sans doute des équivalents pour ARM que tu peux essayer.
Si ta distribution fourni les symboles de debug (debuginfo) pour le paquet correspondant, essaie de relancer gdb après les avoir installés.
Si ta distribution ne fourni pas les symboles de debug, tu peux recompiler le paquet avec CFLAGS+=-ggdb et ainsi récupérer un backtrace ou core plus informatif.
Si le problème est lié au contenu du ring buffer, tu peux tenter de le récupérer indépendamment avec un debugger noyau (crash(8) a une commande "dmesg" interne mais je suis sûr qu'il y en a d'autres).
Si les symboles de debugs ne sont pas disponibles et que recompiler n'est pas pratique, tu peux désassembler la fonction qui merde ("disass" dans gdb ou just objdump -D sur le binaire) et tenter de comprendre le problème comme ça. Avoir le code source correspondant sous les yeux aide beaucoup.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.