Speicherberserker finden???

StefanKittel

Hallo,

ich verwende VS2008 (c++) und habe nun ein richtiges Problem.
Mein Programm funktioniert fehlerfrei ohne Abstürze. Füge ich nun eine Klass zum speichern in einer ODBC Datenbank hinzu, stürzt das Programm an den verschiedensten Stellen ab.

z.B.
CException->Delete
CDBException->Delete
CString::GetLength()

Problem: Die Klasse ist, soweit ich das beurtleiten kann, fehlerfrei. Ich verwende sie schon länger ohne Problem in anderen Projektn.

Da in einige Pointern CException z.B. einfach NULL oder Müll steht, vermute ich, dass irgendwas quer durch den Speicher müllt. Der Fehler läßt sich auch nicht reproduzieren. Mal tritt er nach 2 Sekunden mal nach 5 Minuten auf.

Da, das Programm gebrauch von Multithreading macht, ist das debuggen nicht einfacher.

Was würdet Ihr vorschlagen um den Fehler zu finden?
Ich bin für Tipps dankbar.

Stefan

Nexus

Es gibt viele allgemeine Vorgehensweisen, die einem beim Debuggen helfen können. Das Wichtigste ist, die Fehlerquelle fortlaufend einzuschränken (tönt jetzt selbstverständlich, aber ist gar nicht immer so einfach). Hier einige Tipps:

Beschränke den Code auf ein Minimum. Versuch, ohne gewisse Klassen und Funktionen zu kompilieren. Wenn möglich, deaktiviere auch zeitweise andere Threads.
Geh im Debugger schrittweise durch. Platziere strategisch wichtige Haltepunkte, und überprüf ständig die Werte der Variablen. Gerade wenn sie vorher noch valid waren, kann man so relativ schnell herausfinden, wann - und viel wichtiger, wo - sie überschrieben werden.
Wenn du eine Fehlerquelle lokalisiert hast oder zumindest verdächtigst, überprüf noch einmal genau die Syntax und überleg dir, ob wirklich getan wird, was du willst.
Tu dasselbe auch für Stellen im Code, die du für ziemlich sicher hältst, aber trotzdem einiges Gefahrenpotenzial aufbringen (z.B. Arrayzugriffe, Operationen mit rohen Zeigern). Besser, man prüft einmal zu viel als zu wenig.
Nur weil Dinge lange gut gelaufen sind, sollte man sie nicht voreilig von der Fehlersuche ausschliessen. Gerade wenn undefiniertes Verhalten im Spiel ist, kann Code lange ohne Probleme funktionieren. In so einem Fall prüft man Altbewährtes lieber noch einmal (gilt natürlich nicht für Standardbibliothek etc.), als dass man sich nachher über die verschwendete Zeit aufregt, "dabei wäre es doch so naheliegend gewesen".
Teste. Kompiliere bereits nach kleinen Veränderungen erneut, sonst kannst du vielleicht nicht nachvollziehen, was jetzt ausschlaggebend war. Das gilt übrigens nicht nur beim Debuggen, sondern auch beim Schreiben des Codes. Sei geduldig und probier auch viele Kombinationen aus, so kommst du den Fehlern näher.