"Interressanter" Speicherzugriffsfehler

[Odzilla]

Ich stehe vor einem kleinen Rätsel:

Ich habe eine Klasse, die als Glied einer verketteten Liste fungiert und einen Pointer auf eine Datenklasse enthält.

Ich habe zwei verschiedene Methoden der Klasse, die in der verketteten Liste hängt, die dieselbe funktion der Datenklasse aufrufen. Leider stürzt das Programm bei einem Aufruf ab, beim andren jedoch nicht.


cMyData * cInternalNode::Search(cMyData * theData)
{
if(MY_DEBUG)cout << "cInternalNode::Search()" << endl;
if(MY_DEBUG)cout << "myData: " << myData << endl;
myData->Show(); // <- hier funktionierts
[...] }

void cInternalNode::Show()
{
if(MY_DEBUG)cout << "cInternalNode::Show()" << endl;
if(MY_DEBUG)cout << "myData: " << myData << endl;
myData->Show(); // <- hier gibts nen segfault
[...] }


Ich bin ratlos .. wie kann es sein, dass die Funktion mal geht und mal nicht?
btw: myData hat bei beiden Aufrufen den selben Wert, zeigt also auf dieselbe Instanz der Datenklasse.

Ein theoretischer Ansatz, wie sowas möglich ist wäre schonmal genug *gg*

[locus vivendi]

Ich bin ratlos .. wie kann es sein, dass die Funktion mal geht und mal nicht?
Das ist so gut wie immer die falsche Frage. Eigentlich müsste die Frage lauten "Warum sollte die Funktion immer das gleiche Fehlerverhalten zeigen?" Mit deiner Frage versuchst du nämlich in den Fehler mehr hinein zu interpretieren als drin steckt. Für den Fehlerfall geben verbreitete C++-Implementierungen wenige Garantien. Man sollte also kein systematisches Verhalten erwarten.

[Odzilla]

Naja ... später im Programmablauf bekomme ich immer das selbe: Segfault

Aber der Fehler deutet doch darauf hin, dass myData seine Gültigkeit verloren hat. Andererseits liefert die Funktion ja das richtige Ergebnis.

Naja werd mir mal den Speicherbereich anschaun.

edit:
Naja man braucht nur nen Kaffee, dann löst sich alles :)
Ka warum, aber jetzt scheints zu laufen.

Trotzdem Danke :)

[RapidMax]

Speicherzugriffsfehler wirken sich oft erst später aus. Wenn z.B. ein uninitialisierter Zeiger verwendet wird oder über den Rand eines Buffer gelesen wird, zeigt sich der Fehler direkt. Oft passiert es, dass irgendwo Speicher überschrieben wird, der erst später zu einem Fehler führt. Und da das vom Zustand des Programms abhängt passiert das nicht regelmässig.

Ein sehr beliebter Fehler ist z.B. das zweifache Freigeben von Speicher. Damit zerstört man malloc-interne Strukturen, die erst beim nächsten oder übernächsten malloc() zu einem Segfault führen.

Solche Fehler verhindert man am besten in dem man sauber, überlegt und konsequent programmiert.

Kommt man in den Genuss ein fremdes Programm auf solche Fehler zu überprüfen, so kann man die Debug-Funktionen der libc malloc Funktion nutzen, malloc Debugging libraries verwenden oder Tools wie valgrind einsetzen. Oder noch besser: Das Programm neu schreiben.

Gruss, Andy

[Odzilla]

In diesem Fall: Mal wieder neu schreiben :)

Das nachträgliche Umstellen des Programms auf das Benutzen von Threads war keine allzu blendende Idee ^^