3. Debugging / Fehlerangabe in STL Header

Debugging / Fehlerangabe in STL Header

  • Mod

    Der Fehler liegt mit 99.999999% nicht in der STL, sondern da drin, wie du sie benutzt. in einem optimierten Programm hat die STL normalerweise keinerlei Sicherheitsabfragen, d.h. wenn du etwas falsch machst, dann kracht es eben dort. Schuld ist aber dein Programm. Gehe mal im Stackframe nach oben, bis zu deinem Programm. Dann weißt du, wo der Fehler fliegt und kannst dir dann erschließen, warum. Oder falls du es dir nicht erschließen kannst, dann setz mal so etwas wie valgrind auf dein Programm an (leider nur unter Linux-artigen Systemen, k.A. ob es ähnliches für Windows gibt), damit findet man erfahrungsgemäß recht flott die Ursache solcher Probleme.

    Oder benutz eine Debugversion der STL.

    P.S.: Bei der Fehlermeldung hast du übrigens den interessanten Teil weggelassen. Nämlich den Fehler.

    0
  • Z

    Danke erstmal. Ja, ich habe vergessen zu sagen dass ich Windows Vista nutze. Dass der Fehler nicht in der STL liegt habe ich mir auch zu 99,999999% gedacht. Ich nutze auch den Call Stack. Ich habe mal ein Foto hochgeladen. Das Problem ist nur, ich hab nichts am Code geändert. Und der Code der hinzugefügt/geändert wurde, ist auskommentiert.
    http://s14.directupload.net/images/111229/4uz5htio.jpg

    Vorher waren nicht all diese Fehler vorhanden.

    Auch im Release funktioniert es nicht.

    Nur gibt es sonst eine Möglichkeit, herauszufinden, wo die Initialisierung fehlerhaft ist? Kann es sein, dass es sich um den Vektor geht, welcher so aufgebaut ist:

    std::vector<std::vector<std::string> > vect(2, std::vector<std::string>());

    Normalerweise erhalte ich die Daten über einen blocking Socket und wird dann initialisiert. Auch ohne Daten zu erhalten, läuft das Programm weiter - wie ich gerade bemerkt habe... 🙄 hm, aber eine direkte Fehlermeldung erhalte ich nicht.

    Program received signal SIGSEGV, Segmentation fault.
    In std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () ()
    At c:/program files/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/include/c++/bits/stl_uninitialized.h:74

    0
  • D

    Wo bringt deine IDE dich denn hin wenn du auf Nr. 7 in deinem Callstack klickst? Irgendwas passiert in Zeile 114 in der Datei, in der getvaluesfromrecv::getvaluesfromrecvfunction definiert ist. Da schiebst du irgendwas in einen vector.

    0
  • V

    zuckerlie schrieb:

    Ich nutze auch den Call Stack.

    Gut. Im Call-Stack-Window klickst Du natürlich auf Deinen Nutzcode, die getvaluesfromrecv wohl, und machst noch ein Watch-Fenster für lokale Variablen auf und inspizierst die. Und immer auch mal this anschauen. Manchmal ist this==0 und dann geht alles schief, obwohl alles richtig aussieht.

    0
  • Z

    Ach verdammte Scheisse 😡

    Man sollte seinen Vector für jeden neuen Aufruf wieder leeren. 👎

    Also es liegt scheinbar daran. Aber wieder was gelernt :).

    Aber nebenbei, debuggen waren bei 30,40 Zeilen Code nie ein Problem. Allerdings fängt es jetzt eins zu werden, wenn man insgesamt auf paar hundert Zeilen Code 😞

    Gibt es wohlmöglich Tutorials, wie man richtig "debuggt"?

    Danke Leute 🙂 Ihr habt mir mein Leben gerettet

    0
  • N

    zuckerlie schrieb:

    Danke Leute 🙂 Ihr habt mir mein Leben gerettet

    Scheint sich um wichtigen Code zu handeln, wie? 🤡

    zuckerlie schrieb:

    Gibt es wohlmöglich Tutorials, wie man richtig "debuggt"?

    Wüsste ich keins, aber gibts wahrscheinlich schon. Am besten kombinierst du die Features des Debuggers, damit hast du mächtige Werkzeuge zur Hand (Haltepunkte, Variablen- und Ausdrucküberwachung, Callstack, schrittweises Durchgehen).

    Wichtiger finde ich allerdings Techniken, mit denen man Debug-Sessions enorm verkürzen kann:

    • Vermeide Low-Level-Sprachmittel wie manuelle Speicherverwaltung, mehrfache Zeigerindirektionen, Arrays, C-Strings und ersetze sie durch gekapselte Äquivalente (Container, Smart-Pointer, spezialisierte Klassen). Das macht deinen Code nicht nur sicherer, sondern auch einfacher und übersichtlicher.
    • Halte Abhängigkeiten zwischen einzelnen Modulen klein und verzichte weitgehend auf globale Variablen, Singletons o.Ä. Dadurch bleiben auch Fehler lokal, haben weniger Seiteneffekte und können somit schneller gefunden werden.
    • Benutze Assertions und Klassen, die sie ebenfalls einsetzen (jede vernünftige STL-Implementierung sollte diverse Checks im Debug-Modus durchführen können).
    • Achte darauf, Logikfehler nicht zu vernebeln. Wenn eine Funktion ungültige Parameter bekommt, lass sie nicht einfach weiterlaufen oder normal beenden, sondern reagiere sofort darauf (bei Logikfehlern mit assert ). Damit verhinderst du, dass sich der Fehler weiterzieht und dann an einem Ort Probleme verursacht, wo er schwer nachvollziehbar ist.
    • Passe auf heimtückische Gefahrenquellen auf: Ungültige Iteratoren, Zeiger und Referenzen; Reihenfolge der Konstruktor-Initialisierungsliste; Aufrufe virtueller Methoden im Konstruktor und Destruktor; Slicing; etc.
    • Bastle bestehende Implementierungen nicht unnötigerweise nach. Die Standardbibliothek und Boost bieten für sehr viele Probleme Lösungsansätze. Nutze diese, denn die Wahrscheinlichkeit ist hoch, dass sie getestet und optimiert sind.
    • Setze auf bekannte Idiome wie RAII oder Copy-and-Swap. Als Folge davon bekommst du Exceptionsicherheit und automatische Speicherverwaltung oft gratis.
    0
  • P

    zuckerlie schrieb:

    Gibt es wohlmöglich Tutorials, wie man richtig "debuggt"?

    Nicht dass ichs wüsste - Erfahrung ist da nicht zu ersetzen.

    0
  • Z

    Vielen Dank!

    Scheint sich um wichtigen Code zu handeln, wie? 🤡

    Ja 😃

    Ja, in die Features arbeite ich mich ein. Aber das bedarf auch Zeit 🙂 Vielen Dank für die Punkte!

    Nicht dass ichs wüsste - Erfahrung ist da nicht zu ersetzen.

    Natürlich, nichts ist besser, als Erfahrung 🙂

    0
  • Mod

    zuckerlie schrieb:

    Gibt es wohlmöglich Tutorials, wie man richtig "debuggt"?

    Also mir hat in meiner Anfangszeit dies sehr geholfen:
    Peter's gdb Tutorial
    Das ist natürlich, wie der Name schon sagt, für den GNU Debugger, nicht für den Visual Studio Debugger. Es enthält aber auch viele allgemeine Vorgehensweisen und Techniken, insbesondere der Abschnitt "Debugging with your Brain". Dieser setzt aber voraus, dass du Brain.exe installiert hast 🤡 .

    0
  • ?

    Debug It! | ISBN: 193435628X

    0
  • Z

    Danke 🙂

    Ja, ich nutze den GNU Debugger 🙂 Visual Studio ist nicht so mein Ding 😉

    Brain.exe - Einfach nur TOP die Seite 😃

    Ich werde mir das Buch mal anschauen.

    0
Anmelden zum Antworten