IdHTTP+Memory Leak bei BasicAuthentication, Fix-Check

Narses · Verfasst: Di 28.12.10 01:05

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:

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:

markieren

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;
// +++ Modification by Narses, 27.12.2010
    destructor Destroy; override; // Memory Leak, wenn BasicAuthentication verwendet wird
// ---
    procedure Clear; override;
    //...

implementation

// +++ Modification by Narses, 27.12.2010
destructor TIdRequestHeaderInfo.Destroy;
begin
  if FBasicByDefault and Assigned(Authentication) then
    FreeAndNil(Authentication); // Memory Leak, wenn BasicAuthentication verwendet wird
  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

_________________
There are 10 types of people - those who understand binary and those who don´t.

jaenicke · Verfasst: 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:

markieren

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.

Narses · Verfasst: Di 28.12.10 11:46

Moin!

Thanx.

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme