Narses - Di 28.12.10 01:05
Titel: IdHTTP+Memory Leak bei BasicAuthentication, Fix-Check
Moin!
Ich habe hier leider ein Problem mit der Indy-HTTP-Komponente (v9.?irgendwas), wenn ich BasicAuthentication verwende. Dann liefert mir MemCheck einen feinen Fehlerbericht beim Beenden des Programms... :roll: Benutzt man nur eine statische Kompo auf dem Formular, ist das nicht soo schlimm, dann gibt es nur ein Leck, wenn man allerdings, z.B. bei Nutzung in Threads, die Kompo mehrfach dynamisch erzeugt und wieder frei gibt, dann sammelt sich da was an. :shock:
Tante Google sagt, das sei bekannt, habe auch ein paar Threads in unterschiedlichen Verwesungszuständen gefunden :?, aber keine praktikable Lösung. :nixweiss: Viel besser, in einem Thread wurde angemerkt, dass sei der Indy-Crew bekannt, aber man fände keine gute Stelle, wie man das Leck wieder stopfen sollte, also hat man´s erstmal so gelassen... :nut: :lol:
fragt sich noch einer, warum ich ungerne Indy benutze? Und was Abwärtskompatibilität angeht: ich schreibe doch nicht bei jedem major release meinen kompletten Code um... eigentlich kann man da nur die Finger von lassen...
Nüja, manchmal kann man sich das nicht wirklich aussuchen, also ich habe jetzt diese blöde http-Kompo hier und muss das zum Laufen kriegen (nein, ich kann keine andere Indy-Version nehmen - nebenbei, wäre mir nichtmal sicher, ob das in Indy 10.x tatsächlich gefixed ist). :eyes: Testprojekt angelegt und der Sache nachgegangen. Dazu muss man sich die IdHTTP.pas (um den Versionsfehler beim Compilieren zu vermeiden) und die IdHTTPHeaderInfo.pas in das Testprojektverzeichnis kopieren, dann wird die lokale Version der Units im Build verwendet. Wobei der eigentliche fix nur in der IdHTTPHeaderInfo.pas drin ist, wie´s aussieht, kann man das hier stopfen:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
| TIdRequestHeaderInfo = class(TIdEntityHeaderInfo)
protected
FAccept: string;
public
Authentication: TIdAuthentication;
destructor Destroy; override; procedure Clear; override;
implementation
destructor TIdRequestHeaderInfo.Destroy;
begin
if FBasicByDefault and Assigned(Authentication) then
FreeAndNil(Authentication); inherited;
end; |
Tja, ist mir immer unangenehm an Kompo-Quelltexten zu schrauben, die dann in kommerziellen Projekten verwendet werden, wenn man sich nicht über die Konsequenzen in letzter Sache sicher sein kann (dazu ist das Indy-Projekt einfach zu unübersichtlich; andererseits ist das zwar auch "nur" das Netz, das in meiner Verantwortung liegt, aber das macht es nicht besser :|).
Hat mal grad einer Lust und Zeit, da drüber zu sehen? Das Problem zu fixen ist ja nicht so ganz uninteressant aus öffentlicher Sicht. :idea:
Also:
Request
For
Comment! ;)
cu
Narses
jaenicke - Di 28.12.10 06:11
 Narses hat folgendes geschrieben  : |
| nein, ich kann keine andere Indy-Version nehmen - nebenbei, wäre mir nichtmal sicher, ob das in Indy 10.x tatsächlich gefixed ist |
Ja, ist es. ;-)
Und da sieht der Code so aus:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
| destructor TIdRequestHeaderInfo.Destroy;
begin
FreeAndNil(FAuthentication);
FreeAndNil(FRanges);
inherited Destroy;
end; |
Du hast also schon die richtige Stelle gefunden, also alles in Ordnung wie du es hast. ;-) Da ohnehin geprüft wird, ob der Wert nil ist vor der Freigabe, kann man sich die if Abfrage auch sparen, aber wenn das Feld nur dann zugewiesen ist, ist das ja egal.