Stack-Überlauf bei TClientSocket

dagsta

Hi

Also ich habe einen TClientSocket auf dem ich eine Datei empfange!

Das klappt auch ganz gut nur wenn die Datei zu gross ist bekomme ich einen Stack Überlauf:

..Exccption der Klasse EStackOverflow aufgetreten.Medlung: 'Stack-Überlauf'.

Mein Source:

void __fastcall TForm1::SocketRead(TObject *Sender,
      TCustomWinSocket *Socket)
{
  AnsiString mComp = Socket->ReceiveText();
  AnsiString mSend;
  AnsiString mGet;
  int laenge;
  if(!GetFileData)
  {
    //Wenn keine Dateidaten erwartet werden
    ...
  }
  else
  {
    //Dateidaten werden erwartet
    //Prüfen ob Noch RestDaten da sind...
    if(SaveMessagePart.Length() > 0)
    {
      //Wenn noch Restdaten da sind diese in mComp einfügen
      mComp = SaveMessagePart + mComp;
      SaveMessagePart = "";
    }
    while(CompFileData > CountFileData && mComp.Length() > 0)
    {
      sGetFile.put(mComp[1]);
      CountFileData++;
      mComp.Delete(1,1);
    }
    SaveMessagePart = mComp;  // Den Rest (z.B. nächster Befehl) abspeichern
    if(CountFileData >= CompFileData)
    {
      GetFileData = false;
    }
    SocketRead(Sender,Socket);  // Damit Daten in SaveMessagePart verarbeitet werden auch wenn kein neues OnRead kommt
  }
}

Meine Vermutung ist, dass sich wärend des durchlaufens auf dem Socket soviele daten ansammeln, dass er probleme hat diese in den AnsiString zu packen! Weil der Fehler erst beim 2. Durchlauf auftritt! Kann das sein?

Würde das auslesen der Daten aus dem Stream hier abhilfe schaffen oder nicht? Habe keine Lust die Ganze Methode umzuschreiben wenn es garnicht daran liegt!

THX

Dagsta

junix

Steppe mal einfach mit dem Debugger durch und dir fällt was auf...

-junix

dagsta

So bin jetzt doch wieder auf die 1. Variante umgestiegen aber prüfe jetzt ob überhaupt noch Restdaten da sind bevor ich die Funktion erneut aufrufe und siehe da es klappt!

THX

--------------------------------------------------------------------------

Ja mir fällt was auf!

Wenn ich debugge tritt der Fehler garnicht erst auf!

Dann wird die datei ordentlich übertragen!

Habe noch was am Code verändert:

AnsiString mComp;
  AnsiString mSend;
  AnsiString mGet;
  int laenge;
  //Wenn keine Dateidaten erwartet werden (sonst ormatierungsfehler)
  if(!GetFileData)
  {
    ...
  }
  else
  {
    //Dateidaten werden erwartet
    //Prüfen ob Noch RestDaten da sind...
    puffer[383] = '\0';

    while(CountFileData < CompFileData && Socket->ReceiveLength() > 0 && Socket->ReceiveBuf(&puffer, 383) > -1)
    {
      mComp = AnsiString(puffer);
      if(SaveMessagePart.Length() > 0)
      {
        //Wenn noch Restdaten da sind diese in mComp einfügen
        mComp = SaveMessagePart + mComp;
        SaveMessagePart = "";
      }
      while(CompFileData > CountFileData && mComp.Length() > 0)
      {
        sGetFile.put(mComp[1]);
        CountFileData++;
        mComp.Delete(1,1);
      }
      SaveMessagePart = mComp;
    }
    if(CountFileData >= CompFileData)
    {
      GetFileData = false;
    }
    SocketRead(Sender,Socket);
  }
}

Und der Fehler tritt wenn ich es so durchlaufen lasse weiterhin auf und zwar bei

while(CountFileData < CompFileData && Socket->ReceiveLength() > 0 && Socket->ReceiveBuf(&puffer, 383) > -1)

Aber wenn ich gebugge und meinen Finger auf F9 halte (die Datei ist 600Kb also dauert das ne weile) dann tritt der Fehler garnicht erst auf!

Jemand ne Idee?

THX

Dagsta

PuppetMaster2k

Du überträgst eine Datei und empfängst sie in einem AnsiString? Normalerweise würde man bei Dateien einen Stream (File- oder MemoryStream) nutzen, anstatt den Inhalt der Datei in einen AnsiString zu packen.

Zumindest wäre das meine Idee und wenn ich mich nicht irre, auch die von einigen anderen hier.

junix

dagsta schrieb:

Ja mir fällt was auf!

Wenn ich debugge tritt der Fehler garnicht erst auf!

Doch... aber VIIIEEEL später... Wie soll jemals aus deiner Funktion herausgesprungen werden, wenn du kurz vor dem Sprung eine Rekursion machst?

Übrigens sind Schleifen in Events eigentlich eher nicht wirklich brauchbar... Das Event wird ja mehrfach aufgerufen. Also wieso nicht damit eine "implizite Schleife" bauen?

-junix