Jpeg Speicherleck?

[Gruber_Hans_12345]

Weiss jemand, ob die JPEG unit von delphi ein speicherleck hat?

ich habe mal einen groben test, wo ich immer unterschiedliche JPGs lade, und diese in ein bitmap zeichne, da wächst der speicher schnell auf 1 gb an,
wenn ich das gleiche mache, aber das LoadFromfile nur beim ersten mal im jpg mache (rest bleibt gleich), dann bleibt der speicherkosum gleich.

Werde mal versuchen ein kleines TEstprogramm zu basteln, aber falls schon wer was weiss, bitte melden

Gibt es eigetnlich wo eine freie open source JPGE Unit für delphi? Bei der originalen ist ja kein source dabei ....

[Satty67]

GraphicEx finde ich sehr gut, aber vielleicht zu groß wenn nur JPEG gebraucht wird.

[Klaus01]

Zitat von Gruber_Hans_12345:

Weiss jemand, ob die JPEG unit von delphi ein speicherleck hat?

ich habe mal einen groben test, wo ich immer unterschiedliche JPGs lade, und diese in ein bitmap zeichne, da wächst der speicher schnell auf 1 gb an,
.

Guten Abend,

gibst Du das jpeg wieder frei nachdem Du es in ein Bitmap gezeichnet hast?

Grüße
Klaus

[Gruber_Hans_12345]

Ja, habe einmal versucht jedesmal ein TJPEG zu erzegen und wieder freizugeben
und beim zweiten test ein einziges TJPEGImag, einmal Create und einmal free, dazwischen haufenweise memoryeaks ...

GraphixEx, das hat doch gar kein eigenes Jpeg Image oder?
zumindest meine Version nicht ...

[Gruber_Hans_12345]

hmmm, mist, es hat schon wieder was mit dem thread zu tun.

Selbe funkton im thread ausgeführt ergib massig memoryleak, im hautpthread, kein problem.

[edit]HAbe es auch mit TBitmap32.LoadFromFile('*.jpg') probiert, wenn man es in einem Thread macht, hat man sofort ein Speicherleck, im hauptthread geht es ....

hrmpffff... brauche jetzt eine jpeg komponente, die nicht so löchrig ist ....

[edit2]ach, weiss nicht, hat doch was mit stretchblt zu tun?!?!?!?!

[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.