Forum Linux.général Où poster ce bug et comment?

Posté par (page perso) . Licence CC by-sa
Tags : aucun
1
3
nov.
2014

Bonjour,

J'ai ce bug:
odroid-u3 ~ # gdb /bin/dmesg
GNU gdb (Gentoo 7.6.2 p1) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7a-hardfloat-linux-gnueabi".
For bug reporting instructions, please see:
http://bugs.gentoo.org/
Reading symbols from /bin/dmesg…done.
(gdb) run
Starting program: /bin/dmesg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x2a005f7c in color_fdisable ()
(gdb) bt
#0 0x2a005f7c in color_fdisable ()
(gdb)

Où et comment le poster?
J'ai un doute si je dois le poster à gentoo, https://www.kernel.org/pub/linux/utils/util-linux/ (si oui ou?)…
Et quel sont les infos qui seraient utiles.

Si vous pouviez m'aider? Cordialement,

  • # ton environnement, ta distrib

    Posté par . Évalué à 2.

    Et quel sont les infos qui serai utiles.

    d'apres la ligne

    This GDB was configured as "armv7a-hardfloat-linux-gnueabi".

    tu tournes sur un processeur armv7, donc plutot une tablette, un smartphone, ou une architecture embarquée,
    cela pourrait etre sympa de preciser sur quelle machine et quel OS (visiblement gentoo) tu cherches à faire tourner GDB.

    ensuite on voit, toujours sur la meme ligne, que ca veut utiliser une option hardfloatqui doit permettre, j'imagine d'utiliser des nombres flottants directement à partir du processeur (sans passer par une emulation logiciel)

    ton processeur possede-t-il un jeu d'instruction permettant le hardfloat ?

    • [^] # Re: ton environnement, ta distrib

      Posté par (page perso) . Évalué à 2.

      J'ai cubox-i armv7, rpi armv6, et seul odroid armv7 pourtant trés proche voir identique niveau config bug.
      La seul différence notable étant le noyau (c'est le seul arm avec un noyau vanilla, et en 3.17)
      Oui, il y as le hard float et SIMD (neon):
      half thumb fastmult vfp edsp neon vfpv3 tls vfpd32

      Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

      • [^] # Re: ton environnement, ta distrib

        Posté par . Évalué à 2.

        La seul différence notable étant le noyau (c'est le seul arm avec un noyau vanilla, et en 3.17)

        ca a deja son importance puisque beaucoup de chose passe par le noyau,
        suffit alors de ne pas avoir activé une option pour que certaines fonctions ne soient pas dispo.

        compare avec les autres noyaux pour voir.

        Oui, il y as le hard float et SIMD (neon):
        half thumb fastmult vfp edsp neon vfpv3 tls vfpd32

        de meme compare tes options de processeurs savoir s'ils disposent des memes extensions.

  • # rebuild avec -ggdb

    Posté par (page perso) . É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.

    • [^] # Re: rebuild avec -ggdb

      Posté par (page perso) . Évalué à 2.

      En lisant dmesg.c et associés, je suppute que le problème n'apparait pas quand tu passes -L=never ou que tu utilises une version de dmesg suffisamment ancienne pour ne pas avoir le support des couleurs.

      La raison la plus évident pour que color_fdisable() segfault serait que stdout soit invalide mais je ne vois pas vraiment comment ça peut arriver dans dmesg.

      Un strace (est-ce qu'il y a un close(1) avant le segfault ?) et le message exact quand le segfault a lieu hors de gdb (est-ce que ça crash sur une tentative de lecture de 0x0 ou de quelque chose de plus exotique) pourraient aider. Mais un core associé à l'exécutable avec symboles de debug serait sans doute le plus utile.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: rebuild avec -ggdb

        Posté par (page perso) . Évalué à 1. Dernière modification le 05/11/14 à 11:24.

        dmesg -L=never crash aussi.
        https://bugs.gentoo.org/show_bug.cgi?id=528292
        Voila le bug report avec les testes et info que j'ai trouvé.
        Donc des caractères incorrect semble la.

        Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

        • [^] # Re: rebuild avec -ggdb

          Posté par (page perso) . Évalué à 1.

          Sortie valgrind:
          ==21397== Memcheck, a memory error detector
          ==21397== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
          ==21397== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
          ==21397== Command: dmesg
          ==21397==
          ==21397== Invalid write of size 4
          ==21397== at 0x4005194: _dl_start (in /lib/ld-2.19.so)
          ==21397== Address 0xbd8f44cc is not stack'd, malloc'd or (recently) free'd
          ==21397==
          ==21397==
          ==21397== Process terminating with default action of signal 11 (SIGSEGV)
          ==21397== Access not within mapped region at address 0xBD8F44CC
          ==21397== at 0x4005194: _dl_start (in /lib/ld-2.19.so)
          ==21397== If you believe this happened as a result of a stack
          ==21397== overflow in your program's main thread (unlikely but
          ==21397== possible), you can try to increase the size of the
          ==21397== main thread stack using the --main-stacksize= flag.
          ==21397== The main thread stack size used in this run was 8388608.
          ==21397==
          ==21397== HEAP SUMMARY:
          ==21397== in use at exit: 0 bytes in 0 blocks
          ==21397== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
          ==21397==
          ==21397== All heap blocks were freed—no leaks are possible
          ==21397==
          ==21397== For counts of detected and suppressed errors, rerun with: -v
          ==21397== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
          Segmentation fault

          Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

          • [^] # Re: rebuild avec -ggdb

            Posté par (page perso) . Évalué à 2.

            Ben tu la refais après avoir recompilé avec les symboles de debug.

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.