Jpeg Speicherleck?

[WladiD]

Ich weiß, dass dieses Thema jetzt über 2 Jahre alt ist, aber die Problematik wurde hier nicht gelöst und der zugrundeliegende Fehler existiert bis heute noch in Delphi XE!

Dieser Speicherleck entsteht nur, wenn TJPEGImage in mehreren Threads gleichzeitig verwendet wird. Das liegt daran, dass die Methode TJPEGImageFix.Draw nicht Thread-Sicher ist. Das heimtückische daran ist jedoch, dass kein Memory-Manager (z.B. FastMM4) diesen Leak jemals melden wird, denn es gehen keine Referenzen auf Objekte o.ä. verloren, sondern GDI-Handles.

Dieser Bug wurde noch zu CodeGear-Zeiten veröffentlicht und ist dennoch bis dato "Open".

Der einfachste Workaround ist eine Unterklasse von TJPEGImage:

Delphi-Quellcode:

unit JPEGFix;

interface

uses
   Classes, SysUtils, Graphics, Jpeg, Types;

type
   {**
    * Fix for a known issue in TJPEGImage in multithread usage
    *
    * @see http://qc.embarcadero.com/wc/qcmain.aspx?d=55871
    *}
   TJPEGImageFix = class(TJPEGImage)
   protected
      procedure Draw(ACanvas:TCanvas; const Rect:TRect); override;
   end;

implementation

{** TJPEGImageFix **}

procedure TJPEGImageFix.Draw(ACanvas:TCanvas; const Rect:TRect);
begin
   if IsMultiThread then
   begin
      Bitmap.Canvas.Lock;
      try
         inherited;
      finally
         Bitmap.Canvas.Unlock;
      end;
   end
   else
      inherited;
end;

end.

Natürlich müssen die relevanten Stellen die obige Klasse implizit verwenden. Vielleicht ginge es auch über class helper...

Dieser Bug hat mich über 2 Tage beschäftigt und falls mal einer das selbe Problem hat, wird er diesen Thread hoffentlich nützlich finden.

Wie gesagt FastMM4 sagte stets nur: Keine Speicherlecks gefunden, bis ich auf die Idee kam, im Task-Manager die Spalte für GDI-Objekte einzuschalten. Und siehe da, der Zähler lief fröhlich hoch, bis der Prozess keinen Speicher mehr hatte...

[himitsu]

Jupp, der FastMM kann natürlich nur das Beachten, was in ihm abgelegt wurde.

GDI-Handle, Datei-Handle, eigentlich alle Handle, der WideString und auch direkte Speicheranforderungen an Windows oder an andere Bibliotheken laufen nicht über ihn.

[Bernhard Geyer]

Zitat von WladiD:

... und der zugrundeliegende Fehler existiert bis heute noch in Delphi XE!

Der "Fehler" ist eigentlich das alle GDI-Ressourcen eine Thread-Affinität anhaftet. Sie dürfen eigentlich nur im erzeugten Thread verwendet werden. Die fehlende VCL-Threadsicherheit ist der GDI-Thread-Affinität geschultet. Ein einelne Anpassung hier löst nicht das grundsätzliche Problem.

Zitat von WladiD:

Das liegt daran, dass die Methode TJPEGImageFix.Draw nicht Thread-Sicher ist.

Wie vieles ander in der VCL auch nicht. Deshalb: Alles was mit VCL/GUI zu tun hat immer im Hauptthread erledigen oder dafür sorgen das die Ressourcen im entsprechenden Thread erzeugt werden. Wobei hier globale instanzen wie TApplcation/TScreen hier einen trotzdem einen Strich durch die Implementierung machen können.

Zitat von WladiD:

... der Zähler lief fröhlich hoch, bis der Prozess keinen Speicher mehr hatte...

Du meinst eher: Bis Windows dem Prozess den "GUI-Ressourcen-Hahn zugedeht hat". Den "normaler" Speicher hätte der Prozess wohl noch GB-Weise anfordern könnnen.

[WladiD]

Zitat von Bernhard Geyer:

Der "Fehler" ist eigentlich das alle GDI-Ressourcen eine Thread-Affinität anhaftet. Sie dürfen eigentlich nur im erzeugten Thread verwendet werden. Die fehlende VCL-Threadsicherheit ist der GDI-Thread-Affinität geschultet. Ein einelne Anpassung hier löst nicht das grundsätzliche Problem.

Ich habe nicht behauptet, eine allgemeingültige Lösung für alle Probleme der VCL gefunden zu haben.

Zitat von Bernhard Geyer:

Wie vieles ander in der VCL auch nicht. Deshalb: Alles was mit VCL/GUI zu tun hat immer im Hauptthread erledigen oder dafür sorgen das die Ressourcen im entsprechenden Thread erzeugt werden. Wobei hier globale instanzen wie TApplcation/TScreen hier einen trotzdem einen Strich durch die Implementierung machen können.

TCanvas hat einen integrierten Locking-Mechanismus, sodass man durchaus mit allen (vernünftig implementierten) TGraphic-Nachkömmlingen parallel in mehreren Threads arbeiten kann. Das praktiziere ich mit TPngImage, TBitmap und TJvGIFImage erfolgreich ohne irgendwelche Probleme. Nur das TJPEGImage hat zicken gemacht, weil der Lock nicht angewendet wurde und genau das musste nachgeholt werden.

Wer soetwas über Synchronize erledigt, hat wohl den Sinn der Threads nicht begriffen.

Zitat von Bernhard Geyer:

Du meinst eher: Bis Windows dem Prozess den "GUI-Ressourcen-Hahn zugedeht hat". Den "normaler" Speicher hätte der Prozess wohl noch GB-Weise anfordern könnnen.

Du hast recht, aber man kann auch jedes Wort auf die Goldwaage legen und es läuft dennoch auf dasselbe hinaus: Der Prozess wird angehalten und gekillt, weil irgendwelche Limits des BS erreicht wurden.