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 NeoX . Évalué à 2.
d'apres la ligne
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 alpha_one_x86 (site web personnel) . É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 NeoX . Évalué à 2.
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.
de meme compare tes options de processeurs savoir s'ils disposent des memes extensions.
# rebuild avec -ggdb
Posté par Krunch (site web personnel) . É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 Krunch (site web personnel) . É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 alpha_one_x86 (site web personnel) . Évalué à 1. Dernière modification le 05 novembre 2014 à 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 alpha_one_x86 (site web personnel) . É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 Krunch (site web personnel) . É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.
[^] # Re: rebuild avec -ggdb
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Oui, pour dmesg
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.