valgrind Fehler



  • Hallo zusammen,

    ich verwende in der Arbeit ein Programm, das mich langsam Wahnsinnig macht. Möglicherweise bin ich der einzige User, der dieses unter Linux verwendet und ich bekomme ständig irgendwelche komischen und undefinierte Ergebnisse. Daher hab ich mir einfach gedacht, ich lass valgrind mal mit dem Programm laufen und siehe da es gibt mir 29 Error's. Auf einem anderen Linux OS sinds sogar +400. Der Heap scheint in Ordnung zu sein:

    ==8966== HEAP SUMMARY:
    ==8966==     in use at exit: 0 bytes in 0 blocks
    ==8966==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
    

    Allerdings erhalte ich am Ende folgende Meldung:

    .
    .
    .
    ==8966== 
    ==8966== 5 errors in context 15 of 15:
    ==8966== Conditional jump or move depends on uninitialised value(s)
    ==8966==    at 0x478929: _int_free (in /home/shorty/software/xxx/xxx)
    ==8966==    by 0x4DBB7C: fillin_rpath (in /home/shorty/software/xxx/xxx)
    ==8966==    by 0x4DC182: _dl_init_paths (in /home/shorty/software/xxx/xxx)
    ==8966==    by 0x4B56B4: _dl_non_dynamic_init (in /home/shorty/software/xxx/xxx)
    ==8966==    by 0x4B6097: __libc_init_first (in /home/shorty/software/xxx/xxx)
    ==8966==    by 0x45C8D5: (below main) (in /home/shorty/software/xxx/xxx)
    ==8966==  Uninitialised value was created
    ==8966==    at 0x4D93AC: brk (in /home/shorty/software/xxx/xxx)
    ==8966==    by 0x4B2F14: sbrk (in /home/shorty/software/xxx/xxx)
    ==8966==    by 0x45CBE3: __libc_setup_tls (in /home/shorty/software/xxx/xxx)
    ==8966==    by 0x45C88D: (below main) (in /home/shorty/software/xxx/xxx)
    ==8966== 
    ==8966== ERROR SUMMARY: 29 errors from 15 contexts (suppressed: 0 from 0)
    

    Ich hab natürlich keine Chance den Sourcecode zu bekommen. Jedoch würde ich das dem Entwickler zukommen lassen. Allerdings hätte ich erstmal noch eine Frage, ob das Fehler sind, die zu melden sind. Ich versuche täglich aufs neue mit dem Programm zu arbeiten aber jeden Tag erhalte ich neue Probleme. Allgemein würde ich sagen, dass valgrind Probleme nicht unter den Tisch gekehrt werden können, oder doch? Diese Uninitialisierten Felder sehe ich wenn ich mir meine Ergebnisse anschauen möchte. Ich bekomm dann Werte zwischen -e299 bis +e299. Also irgendwelche Artefakte die im Speicher mal waren (zumindest geh ich davon aus).Eine kurze Einschätzung zu oben genannter Valgrind Ausgabe wäre sehr willkommen.

    Danke bereits im voraus.

    Grüße Tobi

    Vielleicht noch zur Vollständigkeit. Ich hab valgrind mit folgenden Attributen laufen lassen (ihr seht daran vllt, dass ich kein Spezialist mit Valgrind bin - debug-flags kann ich natürlich nicht setzten, da ich es nicht kompilieren kann):

    valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 -v --track-fds=yes --track-origins=yes xxx
    

  • Mod

    Vielleicht, vielleicht auch nicht. In Anwendungscode ist obiges praktisch immer ein schwerer Fehler. Wenn ich so etwas aus beispielsweise der Runtimebibliothek bekäme, würde mich das eher nicht weiter kümmern.

    Deine Beschreibung von wegen falscher Berechnungsergebnisse lässt vermuten, dass es sich um Anwendungscode handelt und es tatsächlich ein grober Fehler ist.



  • Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (alle ISO-Standards) in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • Hallo Sepp,

    wie so oft bist du der Erste der sein Wissen teilt. Dankeschön. Vielleicht noch als Info: Das Tool das ich verwende, bzw. die Software wurde selber an der Uni entwickelt und hat anscheinend nun über 1 Millionen Code - Zeilen (Spielt ja keine Rolle in der Verwendung von valgrind). Das Problem ist, dass ich keine Ahnung hab was die Programmieren und auf welchem OS (wobei valgrind das auch auf anderen OS melden müsste, oder kann das OS abhängig sein?). Ich weiß das das Tool bevorzugt auf MAC + Windows entwickelt wird. Es ist definitiv ein Programm mit dem man Dinge in der Metallurgie berechnen kann, die es so nicht als Standard-Bib geben wird. Das ist eine Niesche und demnach würde ich sagen es ist ein reiner Anwendercode.

    Dann werde ich denen das einfachmal zukommenlassen. Selber kann ich ja nichts dran ändern.

    Danke nochmals Sepp.
    Grüße Tobi



  • wenn die mit einem aktuelleren gcc/clang kompilieren können ist der Address-Sanitzier (ASAN) mittlerweile die bessere Wahl

    gcc/g++ -fsanitize=address


Anmelden zum Antworten