std::vector.push_back stürzt ab???

Knuddlbaer

1. Code is immer gut. Kann man viel effektiever Raten.
2. Welche VC Version hast Du ? VC 6 ?
3. Mal rebuild all gemacht ?

CObject* CGM::CreateObject()
{
	CObject* obj = new CObject;
	obj->SetVisibility(false);
	obj->SetEffect(NULL,0,0,0);
	obj->SetPosition(0,0);
	obj->SetColor(&col);
	obj->SetHMan(&m_HMan);
	obj->SetRMan(&m_RMan);

	this->m_vObjectVektor.push_back(obj);
	return this->m_vObjectVektor.back();
}

Das ist die Methode die die Objekte in den Vektor einfügt. CObject hat nen Haufen von Member-Variablen, aber ich denke die aufzuzählen macht keinen Sinn, da es den Vektor eh nicht interressieren dürfte, da er ja Zeiger als Elemente hat. Naja, irgendwie scheint es ihn aber schon zu interressieren, wenns nämlich ne gewisse Anzahl übersteigt steigt push_back aus

2. jo, VC6

3. Jepp, auch gemacht, aber immernoch

Ich hab echt keine Idee mehr....ich weiss nur das was ich mit dem Debugger rausgekriegt hab: push_back ruft insert auf, und insert irgendwann ne methode namens Deallocate oder so ähnlich, und peng, da passierts.

-schau ob std::bad_alloc irgendwo geworfen wird
-prüfe nach ob du den vektor richtig initialisiert hast

Nein, bad_alloc wird nicht geworfen.

vector <CObject*> m_vObjectVektor;

Was soll ich da initialisieren?? Ich weiss ja noch nicht wieviele Objekte ich hinzufügen will, das weiss ich erst zur Laufzeit. Das ist ja grade der Vorteil an nem Vektor.

Knuddlbaer

Hume hat sich um einen [url="http://fara.cs.uni-potsdam.de/~kaufmann/?page=Programming&ProgKNr=1#Code"]STLFix bemüht[/url]. Ich denke das ist Interesannt für Dich.

Ansonsten: Prüfe mal ob Du m_Vector nicht eventuell irgendwo Überschreibst.

Du sagtest es wäre zuvor gegangen, nun Arbeitest Du mit Zeigern. Eventuell irgendwo über eine Speichergrenze geschrieben oder so ?!

Bau Dir mal ein Minimalbeispiel das auf einen Vector CObjekt Objekte ablegt u nd schau ob das geht.

Hmm, den STLFix hab ich installiert, allerdings war nichts für vector dabei
naja, bestimmt isses in Zukunft doch mal nützlich..

Überschreiben tu ich den Vektor auch nicht. Nur am Ende des Programms wird jedes Element Released.

"Du sagtest es wäre zuvor gegangen, nun Arbeitest Du mit Zeigern. Eventuell irgendwo über eine Speichergrenze geschrieben oder so ?! "

da hast du mich falsch verstanden... Ich hatte vorher auch schon Zeiger (wegen der Vererbung). Das einzige was sich gegenüber vorher geändert hat war die Anzahl der Member-Variablen in CObject. Aber wie gesagt, das dürfte eigentlich egal sein, weil der Vektor eh nur Zeiger speichert.
Das komsiche daran ist ja (ich kann mich jetzt irren, das ist nur ne Vermutung) das er trotzdem irgendwo versucht auf einen Zeiger der nicht "valid" ist zuzugreifen, die Fehlermeldung die nämlich kommt ist:
Access Violation Error 0xc0000005

Ich hab etwas gegoogelt, und es scheint verdammt viele Programme zu geben die diese Fehlermeldung ausspucken...Icq, WinWord, Diskfragmenter, Internet Explorer usw. vielleicht ist es auch ein Problem des Betriebssystems.
Oder ich seh wirklich den Wald vor Bäumen nicht, und es liegt doch in meinem Code (aber ich wüsste nicht wo) ich bin mit dem Debugger durchgegangen, nachdem ich mit new den Speicher für das Objekt reserviert hab, und einigen Membervariablen Werte zugewiesen hab, und alles scheint in Ordung zu sein. Und da frag ich mich doch: Was kann schiefgehen das mein Programm abstürzt, wenn die Adresse von reserviertem Speicher an push_back übergeben wird? Und ich denke nichts, solange man den Vektor nicht überschreibt, oder der Fehler direkt in der Vektor-header liegt...

Achja, ich hab den Link nochmal rausgesucht:

http://www.dinkumware.com/vc_fixes.html

Allerdings sieht meine Header irgendwie ziemlich anders aus, ich finde die Stellen die da beschrieben werden nicht so richtig.
Vielleicht sollt ich mir doch mal das Service Pack von Microsoft runterladen. Aber da könnt ich anfangen zu heulen...für VB wird wieder ne Extrawurst gebraten, die müssen nur ihren VB-Kram laden, aber die C++ler die müssen natürlich wieder "Full" downloaden (130 MB!!!!) wunderbar!!

Knuddlbaer

Mal einen psuedosource:

struct test
{
   char [500] test;
   vector<int> myvec;
};

test t;
  memset($t.test,'\0',510);

OHne jetzt genau zu wissen ob der Code correkt ist (springe wieder zu viel zwishcen den Sprachen)

Was wird wohl mit myvec passieren ?

Na der Vektor wird überschrieben, aber man kann einfach austesten ob sowas geschehen ist oder nicht: man platziert die Vektor-Deklaration ganz oben, und schon kann er nicht überschrieben werden (jedenfalls nicht auf die Art).

Hmm...also ich hab mir ne neue stl besorgt:
(und zwar von SGI) http://www.sgi.com/tech/stl/

und die Vektor-Deklaration mal als erste Memervariable gesetzt, ich weiss nicht an was es von den beiden lag, aber jetzt stürzt er erst bei dem 65. Element ab

Knuddlbaer

Ich würde sagen:

Du überschreibst irgendwo den Speicherbereich und killst den Vector damit.

Die Fehlersuche im eigenen Source sollte nun beginnen, Header austauschen umplatzieren... All das sind keine zuverlässige Lösungen.

nachdem ich SP5 installiert habe, geht es in der debug version.
wenn ich die release erstelle, dann schmiert er wieder ab.

virtuell Realisticer

notrix schrieb:

nachdem ich SP5 installiert habe, geht es in der debug version.
wenn ich die release erstelle, dann schmiert er wieder ab.

Hallo,

im Debugmodus wird, meines Wissens nach, jede Variable auf einen definierten
Wert gesetzt, damit es keine Variablen gibt, die in einem undefinierten Zustand
sind.

Wird vielleicht irgendwo ein Zeiger in einem undefinierten Zustand belassen?

mfg
v R

Also, nach der Einbindung eines Loggers, und einer Fehlersuche im Releasemode damit kann ich sagen das es an new liegt. new stürzt ab, wirft auch ne Exception (allerdings nicht bad_alloc, komisch) aber nen wirklichen Fehler kann ich nicht erkennen. Ich greif auf keinen anderen Zeiger zu, aber er stürzt definitiv bei

l.Log("before new object");
	CObject* obj = new CObject();
	l.Log("after new object");

ab. Und zwar nicht beim erstenmal oh nein, da wärs ja zu einfach . Sondern beim 4. mal .

Im Konstruktor von CObject kann auch nix sein, da werden nur ein paar Zeiger auf NULL gesetzt. Ich versteh die Welt langsam nicht mehr.

virtuell Realisticer

notrix schrieb:

Also, nach der Einbindung eines Loggers, und einer Fehlersuche im Releasemode damit kann ich sagen das es an new liegt. new stürzt ab, wirft auch ne Exception (allerdings nicht bad_alloc, komisch) aber nen wirklichen Fehler kann ich nicht erkennen. Ich greif auf keinen anderen Zeiger zu, aber er stürzt definitiv bei
l.Log("before new object");
	CObject* obj = new CObject();
	l.Log("after new object");
ab. Und zwar nicht beim erstenmal oh nein, da wärs ja zu einfach . Sondern beim 4. mal .

Im Konstruktor von CObject kann auch nix sein, da werden nur ein paar Zeiger auf NULL gesetzt. Ich versteh die Welt langsam nicht mehr.

Und werden diese Zeiger irgendwann genutzt, bevor sie auf einem definierten
Wert gesetzt sind? Das is der einzige Grund der mir dazu einfaellt, denn du
sagtst selbst, dass new kein bad_alloc wirft.

Geh doch mal mit dem Debuger in den Konstruktor und schau nach, wo genau
das Programm abstuerzt.

mfg
v R

Knuddlbaer

Mein bisschen Erfahrungsschatz und das bescheidene wissen lassen mich aber weiterhin fest daran festhalten das Du irgendwo über Speichergrenzen hinweg schreibst. Das Verhalten ist in einem solchen Fall undefiniert und da kann alles passieren.

Wie man das am effektievsten sucht ka.

Erster schritt wäre mal alles zu Initialisieren was zu Initialisieren geht.
Ohne den Source kann man hier nur raten.

IMHO liegt es am Überschreiben von Speicher. Da wird auch kein SP etc. helfen. Der Weg den DU gehst das Problem zu beheben ist schlichtweg falsch. Du installierst solange rum bis der Compiler mal nen Source erstellt er zufällig bei Dir auf dem Rechner läuft.