Ich stolpere bereits seit einigen Tagen über ein Problem, welches mich leider erfolgreich davon abhält an meinem aktuellen Projekt, einer kleinen 3D Engine, weiterarbeiten zu können.

Im Speziellen geht es dabei um einen, im Importer/Converter für .obj-3D-Modellfiles auftretenden, Speicherfehler, den ich beim Versuch bekomme, eine vorher angelegte STL-Map zu leeren oder zu deallokieren.

Auf wesentliche Grundzüge beschränkt, lautet der betreffende Code in etwa folgendermaßen:

bool WaveformModel::loadModelData( const char *filename )
{
	[ ... ]

	std::map<string, unsigned short> *mtl_map = new std::map<string, unsigned short>;

	// initialise and read materials from material lib
	if (!initMtlLib(mtl_map))
	{
		error = 2;
		return false;
	}

	// start reading
	ptr = filestart;

	while ( ptr[0] != '\0')
	{
		[ ... ]

		else if ( equalSubstrings(ptr, "usemtl ", 7))
		{
			skipToNextArg();

			int len = 0;
			for(len = 0; ptr[len] != '\t' && ptr[len] != ' ' && ptr[len] != '\n' && ptr[len] != '\0'; len++);
			string mtl_name(ptr, len);

			m_pMeshes[curMesh].m_materialIndex = (*mtl_map)[mtl_name];
		}

		[ ... ]
	}

	//mtl_map->clear();
	delete mtl_map; // absturz!!

Die aufgerufene Funktion initMtlLib:

bool WaveformModel::initMtlLib(std::map<string, unsigned short> *mtl_map)
{
	[ ... ]
	ptr = buffer;
	// read data
	while ( ptr[0] != '\0')
	{
		// skip commentaries
		if ( ptr[0] == '#')
			skipToNextLine();

		// read material names
		else if ( equalSubstrings(ptr, "newmtl ", 7))
		{
			skipToNextArg();
			// determine length of filename
			for(len = 0; ptr[len] != '\n' && ptr[len] != '\0'; len++);

			string mtl_name(ptr, len);
			(*mtl_map)[mtl_name] = cur_mtl;
			cur_mtl++;

			skipToNextLine();
		}
		[ ... ]
	}

	return true;

Grund des Fehlers ist eine fehlgeschlagende Debug Assertion in der Funktion _CrtIsValidHeapPointer(pUserData) in der dbgheap.c.

Der Absturz tritt auf, sobald ich mtl_map->clear(); oder delete mtl_map; aufrufe. Auch mit automatischer Speicherverwaltung, ohne dynamisch über den Zeiger allokierten Memory stürzt das Programm ab, dann beim verlassen der loadModelData() Funktion, wo der Gültigkeitsbereich von mtl_map verlassen und das Objekt freigegeben wird.
Auch eine Behandlung der mtl_map als Klassenmember führte zum gleichen Fehler.
Die Map nimmt alle Werte die ihr zugewiesen wurden richtig auf, auch der Zugriff funktioniert. Die Adresse scheint gültig zu sein und stimmt am Ende mit der zu Beginn überein.
Die einzige, inakzeptable, Möglichkeit die ich gefunden habe den Absturz zu unterdrücken ist die Auskommentierung des Zugriffs auf mtl_map in der initMtlLib-Funktion.

Leider bin ich mit meinem Latein hier wirklich ziemlich am Ende, und dieser Fehler beschäftigt und frustriert mich schon mehrere Tage.
Also wenn jemand etwas Zeit hätte sich das mal anzuschauen und vllt. eine Idee was hier schiefläuft, wäre ich sehr dankbar.

Kompilieren tue ich es, falls das von Belang sein sollte, unter MS VS05. Unter Linux tritt derselbe Fehler jedoch auch auf.

Falls genauere Informationen über den Code benötigt werden, habe ich hier die Quell- und Headerdatei nochmal komplett verlinkt. Ansonsten bitte nochmal Rückfragen falls Teile nicht verstanden werden o.ä..

http://www.baseoftrash.de/WaveformModel.cpp
http://www.baseoftrash.de/WaveformModel.h

Danke.

ich nehme mal an, dass newmtl jeweils die erste Zeile ist, dann ist aber cur_mtl anschließend beim Füllen um eins zu groß, beim letzten Element ist dann cur_mtl == m_numMaterials und du schreibst über die Array-Grenzen hinaus. Überhaupt sind hier zu wenige Prüfungen des Inputs vorhanden.

Es fällt noch auf:
- Die Speicherreservierung ist inkonsistent: viele new(nothrow), nicht immer wird das Ergebnis geprüft (z.B. buffer, dort fehlt auch ein delete[]), aber vereinzelt auch normale news ohne Behandlung
- keine Smartpointer, es dürften einige Lecks enthalten sein
Es kann sinnvoll sein, die nothrow-news durch normale news zu ersetzen und den ganzen Funktionsinhalt in einen try-block zu verschieben. Zudem sollten die nackten Zeiger durch Smartpointer (am Besten scoped_array/scoped/ptr) ersetzt werden. Noch besser wäre ein Standardcontainer: z.B. vector für m_pMaterials

@Der hmmm:
Hab ich mal versucht, bin aber leider nicht wirklich schlau daraus geworden. Zumindest scheint der Fehler auch hier beim deleten der einzelnen Einträge aufzutereten

@camper:

camper schrieb:

ich nehme mal an, dass newmtl jeweils die erste Zeile ist, dann ist aber cur_mtl anschließend beim Füllen um eins zu groß, beim letzten Element ist dann cur_mtl == m_numMaterials und du schreibst über die Array-Grenzen hinaus. Überhaupt sind hier zu wenige Prüfungen des Inputs vorhanden.

Verstehe nicht ganz worauf du hinauswillst.
In einem Material-File können mehrere "newmtl" erzeugt werden. Über die Map bekommt das erste die ID 0 zugewiesen, cur_mtl wird erst danach inkrementiert. Daher schreibe ich auch nicht über die m_numMaterials hinaus.

Das der Input hier nicht groß geprüft wird stimmt natürlich, liegt größtenteils daran, dass ich die Modelle nur einmal durch diesen Converter jagen möchte und danach dann sowieso auf ein internes binäres Datenformat wechseln werde, welches schneller zu laden, rendern und kleiner zu speichern ist.
Einige zusätzliche Warnungen etc. werden natürlich noch eingebaut, aber ich wollte zunächst mal die grundlegende Funktionalität herstellen.

Es fällt noch auf:
- Die Speicherreservierung ist inkonsistent: viele new(nothrow), nicht immer wird das Ergebnis geprüft (z.B. buffer, dort fehlt auch ein delete[]), aber vereinzelt auch normale news ohne Behandlung

Ist in der Gesamtversion des Codes weitestgehend implementiert, auch das delete des buffers. Bei kleineren new-Anweisungen in der größe von wenigen Bytes habe ich mal auf das Fehlerabfangen verzichtet, wird dann ggf. auch noch eingebaut. Halte ich jetzt aber für nicht so zentral.

- keine Smartpointer, es dürften einige Lecks enthalten sein
Es kann sinnvoll sein, die nothrow-news durch normale news zu ersetzen und den ganzen Funktionsinhalt in einen try-block zu verschieben. Zudem sollten die nackten Zeiger durch Smartpointer (am Besten scoped_array/scoped/ptr) ersetzt werden. Noch besser wäre ein Standardcontainer: z.B. vector für m_pMaterials

Den Begriff Smartpointer höre ich ehrlich gesagt zum ersten Mal. Werde mich dahingehend mal etwas umhören.
Dass die Arrays mit den Daten jedoch herkömmliche dyn. Arrays sind hat einen recht simplen Grund: Nach Abschluss des Einlesens werden die in den Arrays stehenden Daten direkt in ein "cooked" Binärfile exportiert, um von dort aus später im Hauptprogramm wieder sehr schnell und platzsparend gelesen werden zu können - hierfür bietet sich eine Realisierung über vector m.E. nicht an.

Wirklich schlauer was meinen Fehler angeht bin ich aber leider immernoch nicht.

@Der hmmm:
Hab ich mal versucht, bin aber leider nicht wirklich schlau daraus geworden. Zumindest scheint der Fehler auch hier beim deleten der einzelnen Einträge aufzutereten

Spricht ja dafür, dass du irgendwas am string kaputt gemacht hast.

camper schrieb:

ich nehme mal an, dass newmtl jeweils die erste Zeile ist, dann ist aber cur_mtl anschließend beim Füllen um eins zu groß, beim letzten Element ist dann cur_mtl == m_numMaterials und du schreibst über die Array-Grenzen hinaus. Überhaupt sind hier zu wenige Prüfungen des Inputs vorhanden.

Verstehe nicht ganz worauf du hinauswillst.
In einem Material-File können mehrere "newmtl" erzeugt werden. Über die Map bekommt das erste die ID 0 zugewiesen, cur_mtl wird erst danach inkrementiert. Daher schreibe ich auch nicht über die m_numMaterials hinaus.

Es geht um die anderen Zugriffe, m_pMaterials[cur_mtl] - falls nach dem letzten "newmtl" noch eine Zeile kommt, die zu einem anderen if-Zweig gehört, greifst du per m_pMaterials[cur_mtl] logischerweise auf das Element hinter dem letzten des Arrays zu - also undefiniertes Verhalten. Deshalb meine Frage nach der Reihenfolge.

Es geht um die anderen Zugriffe, m_pMaterials[cur_mtl] - falls nach dem letzten "newmtl" noch eine Zeile kommt, die zu einem anderen if-Zweig gehört, greifst du per m_pMaterials[cur_mtl] logischerweise auf das Element hinter dem letzten des Arrays zu - also undefiniertes Verhalten. Deshalb meine Frage nach der Reihenfolge.

Ohje, verdammt, du hast Recht! Dieser blöde Fehler ist mir tatsächlich nicht aufgefallen und er war auch wirklich der Grund für den Absturz. Schwierig den Zusammenhang dann zu finden, wenn die Ursache ganz woanders liegt.

Vielen Dank für deine Hilfe!!

@dgrat: Nicht zwangsläufig. Wenn ich Daten in mein m_pMaterial-Array reinschreibe, an eine Stelle für die gar kein Speicherplatz allokiert ist, schreibe ich ggf. irgendwelchen Unsinn in Speicherblöcke die danach folgen, wie hier eben die mtl_map.