Ich habe eine neue Funktion erstellt, in der eine Datei eingelesen werden soll. Nur dazu kommt es gar nicht. Sobald ich mit "new" neuen Speicher für Variablen allokieren möchte, stürzt das Programm ab. Dabei ist es egal ob ich damit eine größere Struktur oder einfach nur ein "char sText = new char[256];" belegen möchte. Das Programm compiliert fehlerfrei und auch der Linker meckert nicht. Wenn ich es danach aber ausführe, hängt Windows sich auf und bringt einen Fehler.

Quelltext schrieb:

bool LoadVernissageFile()
{
FILE *fp;
int iLine=0;

char* sBuffer = new char[256];
...
}

Hier hängt sich das Programm an der Stelle char sBuffer* ... auf. Folgende Fehlermeldung kommt dabei:
Unhandled exception at 0x7c921404 in Test.exe: 0xC0000005: Access violation reading location 0xc11ffff8.

Hat jemand eine Idee woran das liegen könnte? Bei der Ausführung nimmt das Programm lediglich 5 MB im Speicher ein (sagt der Task-Manager). Der ist also lange nicht voll.

Das Programm compiliert fehlerfrei und auch der Linker meckert nicht. Wenn ich es danach aber ausführe, hängt Windows sich auf und bringt einen Fehler.

Ne, Windows hängt sich nicht auf, sonst könnte es keine Fehlermeldung ausgeben.

Quelltext schrieb:

bool LoadVernissageFile()
{
FILE *fp;
int iLine=0;

char* sBuffer = new char[256];
...
}

Hier hängt sich das Programm an der Stelle char sBuffer* ... auf.

Sicher? Passt nämlich nicht zur Fehlermeldung

Folgende Fehlermeldung kommt dabei:
Unhandled exception at 0x7c921404 in Test.exe: 0xC0000005: Access violation reading location 0xc11ffff8.

Hat jemand eine Idee woran das liegen könnte?

An einer anderen codestelle.

Das Programm hängt sich an dieser Stelle auf. Habs mit ner Messagebox ausgetestet. Steht sie vor der Anweisung, wird sie noch angezeigt, steht sie danach, kommt sie nicht mehr. Wählt man dann aber "debug" in der Windows Fehlermeldung, so zeigte diese einem an, dass der genaue Fehler in irgend einer Windows Datei liegt, die den Befehl "malloc" definiert.

Nun aber zeigt er auf einmal das der Fehler in nem ganz anderem Teil der Applikation aufgetreten sein soll. Dort angeblich beim Ende einer Funktion. also der "}". Jetz bin ich noch verwirrter.

keiner der da ne Ahnung hat?

Ich sollte noch hinzufügen, das der Fehler aber wirklich an der besagten Stelle bei der Speicherinitialisierung ausgelöst wird.

keiner der da ne Ahnung hat?

Lerne: Es gibt einen erheblichen Unterschied zwischen "ausgelöst" und "verursacht". Die Speicehrverwaltung bemerkt was immer Du vorher falsch gemacht hast eben erst beim Aufruf von new und wirft deswegen eine Excpetion.

Deshalb muß new den Fehler aber noch lange nicht "verursachen". Sie es mal so, wenn Dir jemand 100 Euro aus der Tasche klaut, dann bist Du ja nicht automatisch der Dieb nur weil Du nachschaust und es bemerkst, oder?

Der Fehler wird garantiert irgendwo anders erzeugt. Und ohne etwas mehr Code als die 2 Zeilen wird Dir da hier auch niemand helfen können.

void EngineMainLoop(void)
{
	MSG message;   // Windows Nachrichten Handle	

	while(g_App.GetD3DStatus())			// D3D Zustand überprüfen
	{
		if(PeekMessage(&message,NULL,0,0,PM_REMOVE))		// Nachrichten auswerten
		{
			TranslateMessage(&message);
			DispatchMessage(&message);
		}

		if(g_App.CheckDevice())				// Wenn Device nicht verloren ist:
		{	
			// Key Countdown  runterzählen
			if (g_iKeyCountdown > 0)
				g_iKeyCountdown--;

			if (g_iMenu == 0)					// Wenn man nicht im Menu ist
			{
				// Das Bild Rendern
				RenderScene();	

		                  // am Ende dieser Funktion (RenderScene()) sagt der Debugger inzwischen das der Fehler aufgetreten ist

				// Direct Input Objekt updaten
				g_pInput->Update();

				// Eingaben prüfen		
				ReadKeyInput();

// Diese Funktion (ReadKeyInput()) löst dann die Ladefunktion aus

				ReadMouseInput();

// ...
// Hier folgen Funktionen zum Rotieren der 3D Objekte
// ...

			}
			else
			{			
				// Menu rendern
				RenderMenu();				
			}
		}	

	}	// ~while(g_App.GetD3DStatus());

}	// ~EngineMainLoop();

void ReadKeyInput()
{

// ...
// Viele Viele Abfragen für Tastendrücke
//

	if (g_pInput->KeyPressed(DIK_V))
	{
		if (g_iVernissageMode == 0)
		{
			if (!LoadVernissageFile()) return;

			g_iVernissageMode = 1;
			g_iVernissageRow = 0;
		}
		else
		{
			g_iVernissageMode = 0;
		}
	}

}	// ~ReadKeyInput();

bool LoadVernissageFile()
{
	FILE *fp;	
	int iLine=0;	

	 char* sBuffer = new char[256];

// ...
// zu Testzwecken alles auskommentiert was die eigentliche Dateiverarbeitung ist
// ...

	if (iLine > 0) 
		return true;
	else
		return false;
}	// ~LoadVernissageFile();

So, da hab ich mal die 3 Funktionen zusammengeschnitten, die nacheinander aufgerufen werden.

Ja das Problem ist das das Program über 10 dateien geht und mehr als 5000 Zeilen Code besitzt. Also das new den Fehler auslöst, der woanders verursacht wird ist schonmal ein Ansatz. Das bedeuted das der Fehler bei irgend einer anderen Speicherallokierung liegen muss, oder?

Nicht zwingend bei der Allokierung. Wenn Du debug-code erzeugst fordert new nicht einfach nur Speicher an sondern macht eine ganze Reihe von Checks ob der Speicher zwischenzeitlich corrumpiert wurde. Ein new selbst kann den Speicher nicht korrumpieren, was Du suchst ist fehlerhafte Freigabe von Speicher, so ind er Art von doppeltem delete-Aufruf oder delete auf ein vorher nicht initialisiertem pointer usw. Wenn Du dir z.B. ein Ojekt anschaust und da sowas wie 0xfeefee drinsteht, dann ist das kein zufall sondern ein vom debug-delete eingetragener Wert um Dir anzuzeigen, daß dieser Speicehr freigegeben wurde. Findest Du sowas in einem Objekt mit dem Du (noch) arbeitest, grenzt das den Fehler schonmal ein...

Wobei solche Fehler erfahrungsgemäß für einen Anfänger schwer zu finden sind...

Ein new selbst kann den Speicher nicht korrumpieren, was Du suchst ist fehlerhafte Freigabe von Speicher, so ind er Art von doppeltem delete-Aufruf oder delete auf ein vorher nicht initialisiertem pointer usw. Wenn Du dir z.B. ein Ojekt anschaust und da sowas wie 0xfeefee drinsteht, dann ist das kein zufall sondern ein vom debug-delete eingetragener Wert um Dir anzuzeigen, daß dieser Speicehr freigegeben wurde. Findest Du sowas in einem Objekt mit dem Du (noch) arbeitest, grenzt das den Fehler schonmal ein...

Hm, vielen Dank schonmal, das ist ein Anfang. Werd das morgen nochmal anschaun. Leider kann ich den Debugger nur eingeschränkt nutzen. Wenn ich Debug starte, dann läuft zwar das Programm als Task, aber das Fenster in dem alles stattfindet öffnet sich nirgends. Keine Ahnung warum. Einzige Möglichkeit ist das Programm als .exe zu compilen, auszuführen und dann beim Absturz auf "debuggen" klicken.

Vielleicht liegts ja irgendwo in der RenderScene(). Wenn ihr noch weitere ideen oder Tips hättet, woran es liegen könnte,bin ich sehr dankbar.

Also zum Problem selber nicht, aber beim Debuggen nehm ich mal an das du die DirectX Anwendung nicht im Vollbildmodus ausführst. Ansonsten änder das am besten mal, damit dein Debugger (und alle anderen Windowsprogramme) es leichter haben

Hab beides schon gemacht. Derzeit läufts im Fenstermodus, damit nicht das ganze Windows sich bei dem Fehler aufhängt. Im Vollbild geht dann nämlich gar nix mehr.

Also hab nun den Fehler eingegrenzt. Es handelt sich tatsächlich um einen Speicherfehler, danke an die, die mich auf den Pfad gebracht haben. Allerdings kann ich ihn nirgends finden. Ich hab nur 2 dynamische Variablen in der Anwendung. Diese werden beide mit new initialisiert und mit delete gelöscht (danach auch noch mit var = NULL; auf Nullzeiger gesetzt).

Der Fehler tritt auch auf, wenn man das Programm normal beendet, also wenn das erste der beiden deletes aufgerufen wird. Dann sagt er:
Unhandled exception at 0x7c920f29 in Test.exe: 0xC0000005: Access violation reading location 0x20bbbbff.

Als Datei zeigt er dann die "free.c" (muss ne Windows Datei sein) und áuf:

retval = HeapFree(_crtheap, 0, pBlock);
if (retval == 0)
{
 errno = _get_errno_from_oserr(GetLastError());
}

Noch ne Idee?
Ich hab nun wirklich alles durchgeschaut. Keine doppelten news oder deletes. Keine Nutzung von uninitialisierten Variablen, etc

Schau doch mal im Call stack nach welches delete den fehler auslöst...

Vielleicht versuchst du einen Zeiger zu löschen, der schon auf Null gesetzt wurde.

Es ist kein fehler einen auf 0 stehenden Zeiger zu löschen. Da passiert einfach nix. z.B.

char* ptr = 0;

delete ptr;

Hat ein klar definiertes Verhalten. da passierts chlicht gar nix.