Stack overflow bei einem Methodenaufruf

Mr.Yellow

Hallo zusammen,

ich habe da mal wieder ein Problem, dass ich nicht so ganz verstehe. Beim Sprung in eine Methode erhalte ich die Fehlermeldung:

Unhandled exception at 0x00648467 in MyApp.exe: 0xC00000FD: Stack overflow.

und ich lande mit dem Debugger in einer Assembler Datei ( chkstk.asm ) in der offensichtlich überprüft wird, ob noch genug Platz auf dem Stack vorhanden ist.

Nun mal zu meiner Methode:

bool MyClass::CheckCrc32Value( CStdioFile &file )
{
   char  acCrc32[ sizeof(DWORD) ];
   DWORD dwCrc32File, dwCrc32Calc;

   BYTE  bTempReadBuffer[8];
   BYTE  bFileBuffer[ MAX_FILE_SIZE ];

   // Read the Crc32 value from the file
   // ----------------------------------
   file.Seek( OFFSET_CRC_VALUE, CFile::begin );

   ...
   return true;

bFileBuffer ist hierbei ein Feld, in dem ich eben ein paar Bytes aus einer Datei speichern will. Früher war dabei MAX_FILE_SIZE auf 33000 definiert und dies habe ich jetzt auf 500000 geändert ( ... es wurden auch noch ein paar mehr Stellen geändert, ich denke aber dass diese nichts mit diesem Problem zu tun haben können ). Seit dem erhalte ich diese Fehlermeldung. Was mich dabei sehr wundert ist, dass ich diese Fehlermeldung schon vor dem Aufruf von

BYTE  bFileBuffer[ MAX_FILE_SIZE ];

erhalte ( mit "vor dem Aufruf" meine ich eben .. ich gehe per Debugger Schritt für Schritt vor ). Der Fehler scheint irgendwie von diesem Wert abzuhängen, aber ich komme mit dem Debugger erst gar nicht zu der Zeile, in der dieser Wert eine Rolle spielt ( Wenn ich kleinere Werte für MAX_FILE_SIZE eintrage funktioniert die Methode einwandfrei ... nur die Dateien sind nun mal bis zu 500000 Byte gross ). Sobald ich von dem Funktionskopf eine Zeile weiter springe erscheint der Fehler.

Prüft der Compiler schon beim Sprung in die Funktion die Aufrufe nach, in denen Speicher auf dem Stack reserviert wird, oder wieso erscheint dieser Fehler schon direkt nach dem Sprung in die Methode?
Es muss doch möglich sein 500kByte auf den Stack zu legen. Oder woran kann es liegen?

Ich verzweifele hier ... wenn mir jemand bitte weiterhelfen kann ... dabei schnappe ich nach jedem Knochen der mir zugeworfen wird.

Mr.Yellow

P.S.:
Da fällt mir gerade ein, dass ich vor 2 Tagen auch erst einen Stack overflow hatte. Das seltsame an der Geschichte war, dass dies bei einem Aufruf des TRACE Makros auftrat.

TRACE( _T( "HIIILLFFEEE!" ) );

CStoll

für lokale Variablen wird direkt beim Start der Funktion genug Speicher auf den Stack gelegt - und 500kB dürften etwas die Kapazitäten des Stacks sprengen
Wenn du wirklich so viel Platz benötigst, solltest du dafür lieber den Heap (new/delete) verwenden, der hat mher Platz.

PS: Oder du liest die Datei nicht als Ganzes ein, sondern in kleineren Häppchen.

net 0

stackspeicher ist immer sehr begrenzt. mach z.b. sowas:
--> BYTE *bFileBuffer = (BYTE*)malloc(MAX_FILE_SIZE * sizeof(BYTE));

und wenn der buffer nicht mehr gebraucht wird:
--> free (bFileBuffer);

oder du machstes mit 'new' oder 'VirtualAlloc' usw.

Mr.Yellow

Ok ... werde ich dann mal alles in den Heap packen. Kann ich leider gerade im Moment nicht ausprobieren ... werde mich aber noch mal melden, wenn es geklappt hat und erst recht wenn es nicht funktioniert. *g*

Pellaeon

Da du mit CStdioFile arbeitest, benutze doch CString. Dann hat sich das eh. Allerdings Achtung wegen ANSI/ASCII-Unterschied!!!

Mr.Yellow

Des Rätsels Lösung:

Vielleicht hätte ich einfach mal etwas mehr von meinem Quellcode posten sollen ich Depp. Ich hatte wohl anscheinend vor, als ich diese Methode geschrieben hatte die BYTE arrays auf den Heap zu packen. Hab nämlich vor dem verlassen der Methode

if( bFileBuffer != NULL )
{
   delete [] bFileBuffer;
}

aufgerufen.

Eine peinliche Angelegenheit, aber ich wollte Euch diesen Faux-Pas nicht vorenthalten.

MFK

Die Prüfung auf != NULL ist überflüssig.