Forum Programmation.c++ Bugs dans g++ ?

Posté par  .
Étiquettes : aucune
0
27
fév.
2007
Bonjour,
Savez-vous si il reste encore beaucoup de bugs dans g++ ?
J'observe un comportement étrange dans un programme que j'écris pour un projet dans le cadre de mes études. C'est une petite IA d'échecs en C++ (mais en réalité, l'informatique n'étant pas ma spécialité, c'est plus du C avec des classes...).

Le code n'est pas supposé pousser g++ dans ses retranchements en terme de compilation, pas de bidouilles exotiques, il est petit (moins de 4000 lignes), etc...

Et pourtant le code fonctionne sans problème pendant 24h compilé avec -g, mais plante presque immédiatement avec -01, -02, -03 ou -0s avec le g++ fourni sur edgy eft, et passe sans problème avec g++-3.3...

Quelqu'un a une idée de la source du problème ? Je sais que sans code ça va être difficile, mais je n'ai pas encore isolé un code court qui provoque le problème.

D'avance merci
  • # To bug or not to bug…

    Posté par  . Évalué à 4.

    Il n'est pas évident qu'il s'agisse de bogues de l'optimisation mais plutôt de bogues qui sont révélés par l'optimisation.

    Certaines constructions peuvent sembler correctes au programmeur mais peuvent poser des problèmes après passage par le compilateur. Celles auxquelles j'ai le plus été confronté concernent les variables ou résultats temporaires. Ces temporaires sont supprimés s'ils ne servent pas (et ils servent avec -g, ne serait-ce que pour en connaître le nom pour le débogage).

    Pour donner un exemple, la classe std::string fournit la méthode c_str() pour récupérer le contenu de la chaîne sous forme de char*. Mais ce char* est temporaire et il est plus sage d'en faire une copie avant de s'en servir.
  • # Valgrind forever

    Posté par  (site web personnel) . Évalué à 4.

    Même si effectivement il y a toujours des bugs potentiels dans gcc et que donc c'est pas à exclure, amha considère que le problème est dans ton code, ce sera vrai dans 99% des cas...

    Ce genre de comportement (bug avec certaines versions de gcc et pas d'autre et selon les options de compimation) est assez classique de problème de gestion de la mémoire. Donc à mon avis, la première chose à faire est de passer ton programme (avec infos de debug) à valgrind et de corriger *toutes* les erreurs que valgrind te dit.

    Même remarque pour valgrind que pour gcc : souvent on se dit "ah ouais mais il a tort" - mais en pratique il se trompe très rarement, surtout sur du code pas trop tricky. La STL fait dire à valgrind des fois que il y a des leaks (pareil pour pthread) mais ce n'est pas les leaks qui sont probablématiques en l'occurrence :)

    Un autre truc à tester, surtout si tu es friand de casts dans ton code, c'est de compiler avec du -fno-strict-aliasing ; les problèmes liés au strict aliasing représentent le bug le plus souvent signalé ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920 ), mais il ne s'agit *pas* d'un bug de gcc. Voir la page de man de gcc pour plus d'infos sur le pkoi du comment du strict-aliasing (en gros, une règle du C dit que deux pointeurs de type différent, par ex. int* et float*, pointent nécessairement sur des données différentes, ce qui permet à gcc de faire des optimisation plus agressives).
  • # -Wall ?

    Posté par  . Évalué à 1.

    Dans le genre flag de compilation qui sauve.
    Accessoirement, corriger *tous* les warnings, c'est *bien* :-)
  • # Merci

    Posté par  . Évalué à 1.

    Merci pour toutes ces réponses.
    Jer suis en train de voir ce que ça donne avec valgrind. Pour l'instant sur le code compilé avec -03 valgrind segfault (après le programme tout de même), je suis en train de voir ce que ça donne sur la version compilée en -g.

    Merci pour le truc des variables temporaires, je penchais aussi pour un problème de mémoire qui est accédée différemment selon les flags d'optimisation... Reste à trouver ça, parce que je e peux pas compiler le programme en -g (le prog tourne presque 3x plus vite avec -O3 !).

    Et sinon, aucun warning avec -Wall...
    • [^] # Re: Merci

      Posté par  . Évalué à 2.

      Ton programme est sous quelle licence ?

      Si c'est en GPL, mets-le en ligne, on trouvera plus vite !
  • # Irrationel

    Posté par  . Évalué à 1.

    C'est facile d'incriminer l'outil immédiatement.
    Donne ton code, ouvre un bug gcc, montre une stacktrace.

    Y a 99,999999% de chance que ton code contienne juste un écrasement de pile plutôt que ce soit g++ qui génère du mauvais code.

    Rasoir d'Ockham.
    • [^] # Re: Irrationel

      Posté par  . Évalué à 1.

      Je n'incriminais pas directement g++, contrairement à ce que le titre du post pourrait le faire croire...
      Je n'ai qu'une connaissance très partielle du C++ et du C, j'étais juste intrigué par le fait que le bug ne se produise qu'avec certaines options de compilation et certaines versions de g++...

      D'ailleurs depuis j'ai trouvé le bug, une écriture au-delà des limites d'un tableau...
      Ca vous donne pas envie de persévérer dans le C++ ce genre de choses. Dans ma jeunesse (classes prépa) OCaml signalait immédiatement ce genre de choses, je ne savais pas que g++ ne savait pas reconnaitre un probleme comme le précédent :


      for ( int i=3 ; i< 7 ; i++ )
      {
      temp_vect[i] = 14+i;
      }


      avec bien sur temp_vect[] qui n'est pas assez grand, et déclaré en variable globale...


      C'est bon à savoir, je ferais attention maintenant.
      Mais bon, les projets d'études quand on a a pas de cours de programmation, faits à plusieurs avec personne qui ne connait vraiment bien la programmation, ça donne forcément ce genre de problèmes...
      • [^] # Re: Irrationel

        Posté par  (site web personnel) . Évalué à 1.

        C'est un grand classique. Le C et le C++ privilégient les perfs aux vérifications. C'est à nous de faire attention.

        Ceci dit, au lieu de faire du C avec des classes, fais du C++. Au lieu d'utiliser un tableau, utilise un std::vector et assure-toi que la S(T)L que tu utilises est "checkée" -- certaines versions de l'opérateur [] des vecteurs vérifient que l'indice soit bon à l'aide d'un assert, ce qui aurait au moins planté le programme en mode debug.

Suivre le flux des commentaires

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