Ich schreibe gerade an einem größeren C++ Projekt und habe mir scheinbar auf dem Weg einen hässlichen bug eingehandelt der mir (glaube ich) stack corruption beschert. Symptome: Programm crasht mit Speicherzugriffsverletzungen an zufälligen (aber je nach user input und RNG-Seed reproduzierbaren) Stellen, teilweise "während" eines returns.

Ich habe soweit möglich STL Objekte und auch Algorithmen verwendet, um die typischen memory allocation Fehler und fencepost errors von vornherein auszuschließen.

Meine eigentliche Frage:
std::vector ist soweit ich weiß im wesentlichen ein Wrapper für C-style arrays, die dynamisch (also auf dem heap) allokiert werden. Wenn also ein Objekt eine Matrix in Form eines vector<vector<unsigned> > als Membervariabel enthält, wird auf dem Stack im wesentlichen nur ein "Pointer" auf den Speicherbereich des äußeren vectors gespeichert? Ich frage, weil ich teilweise potenziell recht lange std::lists und std::vectors by value returnen muss, und ich möchte ausschließen, dass die beim returnen angelegte Kopie mir den stack corrupted oder überlaufen lässt.

Als Bonusantwort (natürlich schwer ohne ein paar Stunden/Tage mit dem Code zu verbringen): Gibt es noch andere "typische" Fehler die man mit der STL machen kann, die das beschriebene Verhalten hervorrufen?

Danke,

Daniel

Ich frage, weil ich teilweise potenziell recht lange std::lists und std::vectors by value returnen muss, und ich möchte ausschließen, dass die beim returnen angelegte Kopie mir den stack corrupted oder überlaufen lässt.

sizeof(std::vector) ist unabhaengig von seiner Laenge oder dessen Inhalt.

ich vermute dass der vector im speicher fragmentiert vorliegen kann,

Kann er nicht (seit dem Corrigendum von 2003).
Simon

Bedenke: Nur wenn du vector.at() nutzt prüft der Vector die Bounds, bei operator[] wird nicht geprüft!

Ansonsten jag doch mal valgrind auf dein Programm.

das hat mich auch nicht sonderlich verwundert, da ich generell von std::vector nicht viel halte.

Wundert mich nicht, wenn jemand gegen die Implementierung statt gegen die Schnittstelle programmiert.

Was valgrind angeht - ich bin leider auf ein Windowssystem beschränkt, muss da mal beim Chef etwas Lobbyarbeit betreiben. Nervt mich eh schon die ganze Zeit, dass die meisten guten Tools nicht laufen ^^

BTW: Wenn Du schon Copy DTOR und Assignment Operator gemacht hast, dürfte ein DTOR auch angebracht sein.

Simon

Für Windows gibts den Application Verifier.

Sofern man MS Visual Studio verwendet.

theta schrieb:

Für Windows gibts den Application Verifier.

Sofern man MS Visual Studio verwendet.

Die Alternative dazu wäre doch wohl MinGW, und für den gibts afaik auch valgrind.

Die Alternative dazu wäre doch wohl MinGW, und für den gibts afaik auch valgrind.

Aber nicht für Windows. Es gibt eine unter wine lauffähige Variante aber das wars auch schon.

theta schrieb:

Für Windows gibts den Application Verifier.

Sofern man MS Visual Studio verwendet.

Muss nicht sein, kann auch separat gestartet werden.
Simon

...aber das wars scheinbar nicht (leider).

Das memcpy nicht unbedingt für Objekte geeignet ist, hast du aber auch verstanden? Und dabei ist es egal ob du auf C-Arrays oder std::vector setzt.

Ich _glaube_ übrigens ich hab den bug exterminiert, kann aber nicht mit Sicherheit sagen, was genau es war. Habe ein größeres refactoring der Methode gemacht, die den Fehler scheinbar verursacht hat, jetzt läufts (wohl).

dgrat schrieb:

das hat mich auch nicht sonderlich verwundert, da ich generell von std::vector nicht viel halte.

Wundert mich nicht, wenn jemand gegen die Implementierung statt gegen die Schnittstelle programmiert.

zynismus ist die sprache schwacher geister.. vermutlich weiste selbser bicht, warum der fehler auftritt.

aber volkard hat wieder recht, in meinem fall bewirkt vector<vector> eine speicherfragmentierung, weil die daten, die wichtig behandelt werden, leider nicht hintereinanderliegen...

zynismus ist die sprache schwacher geister..

Naja, es ist ein wenig einfach, dem vector mal grundsätzlich die Schuld in die Schuhe zu schieben, weil man persönliche (wahrscheinlich noch unbegründete) Abneigungen besitzt.

dgrat schrieb:

aber volkard hat wieder recht, in meinem fall bewirkt vector<vector> eine speicherfragmentierung, weil die daten, die wichtig behandelt werden, leider nicht hintereinanderliegen...

Dann benutzt du eben nicht memcpy() . Sobald nämlich mehr als nur PODs vorliegen, erzielst du damit undefiniertes Verhalten.

Und dass ein verschachtelter std::vector nicht alle Elemente linear hintereinander im Speicher halten kann, dürfte zu erwarten sein. Entweder man kopiert die inneren Container einzeln oder benutzt einen anderen Aufbau der Datenstruktur (eindimensionaler std::vector ).

vermutlich weiste selbser bicht, warum der fehler auftritt.

Mein Persönlicher Verdacht wurde bereits im 2ten Post geäußert, zudem habe ich schon selbst genügend Fehler in Programmen gebaut um auch das Verhalten durchaus zu kennen. Die Ablehnung wiederum vom std::vector, und das zurückgreifen wollen auf eine selbstgebaute Lösung die auf das gleiche hinausläuft ist mehr als Schwachsinn.

Die Macher der Standardbibliothek haben sich schon gute Gedanken gemacht (Und ich behaupte mal das man die Standardbibliothek, gerade bei aktuellen Compilern weitgehend Fehlerfrei bezeichnen kann - vermutlich besser getestet als du es jemals in eigenen Programmteilen hinbekommen wirst).

Es gibt sicherlich auch Punkte die man daran aussetzen kann, aber das was du mit memcpy betreibst funktioniert auch mit C-Arrays nicht (Zumindestens nicht mit vielen Objekttypen).

Und das du mein Abgewandeltes Zitat nicht kennst und darauf auf einen "schwachen Geist" schließt, zeigt mir nur das du nicht wirklich viele Fachbücher kennst, die sich auch mit OO und C++ auseinander setzen ("Programmiere gegen die Schnittstelle, und nicht gegen die Implementierung" ist nicht ohne Grund einer der häufigsten Zitate die ich aus Fachbüchern kenne).

cu André