Vielen Dank für eure Antworten!
Zitat von
hoika:
Indy hat ein paar mem leaks, wo sich keiner rantraut,
weil es zu kompliziert ist.
Die sind aber statisch (einige globale Variablen, die einmal erzeugt und danach nicht freigegeben werden), nicht 23*x oder sowas .
Ich weiß. Die sind auch schon herausgefiltert und können hiermit, da hast du Recht, nichts zu tun haben.
Zitat von
hoika:
Delphi-Quellcode:
AContext.Connection.Tag := Int64(New(PFiRe));
A^.Transaktion := TSQLTransaction.Create(nil);
A^.Anfrage := TSQLQuery.Create(nil);
Wo erfolgt denn die Freigabe dieser Klassen?
Die erfolgt im Disconnectereignis des
TCP-Servers folgendermaßen:
Delphi-Quellcode:
procedure TFirstemServer.TCPServerDisconnect(AContext: TIdContext);
var
A: PFiRe;
begin
WriteLn('Klient getrennt: ' + AContext.Binding.PeerIP + ':' + IntToStr(AContext.Binding.PeerPort));
A := PFiRe(AContext.Connection.Tag);
with A^ do
begin
Anfrage.Free;
Transaktion.Free;
Verbindung.Free;
end;
Dispose(A);
end;
Funktioniert auch. Da werden keine Speicherlecks gemeldet.
Zitat von
hoika:
Fehlendes Close (Zur Sicherheit);
Delphi-Quellcode:
with A^.Anfrage
do
begin
Close;
SQL.Text := '
SELECT passwort FROM nutzer WHERE name = :NAME';
Habe ich ausprobiert. Ändert aber leider nichts.
Zitat von
p80286:
Solchen Konstrukten traue nicht über den Weg
markieren
Delphi-Quellcode:
Kennwort_db := ' - undefined -';
begin
A^.Anfrage.SQL.Text := 'SELECT passwort FROM nutzer WHERE name = :NAME';
A^.Anfrage.Params.ParamByName('NAME').AsString := Nutzername;
A^.Anfrage.Open;
if not A^.Anfrage.EOF then
Kennwort_db := FieldByName('passwort').AsString;
A^.Anfrage.Close;
end;
versuch es mal so.
Auch das hat leider nichts geändert (auch wenn es so schön vielversprechend aussah...). Ich bekomme die gleichen Speicherleckmeldungen...