AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Jpeg Speicherleck?

Ein Thema von Gruber_Hans_12345 · begonnen am 18. Mär 2009 · letzter Beitrag vom 26. Apr 2011
Antwort Antwort
WladiD

Registriert seit: 27. Jan 2006
Ort: Celle
146 Beiträge
 
Delphi 11 Alexandria
 
#1

AW: Jpeg Speicherleck?

  Alt 26. Apr 2011, 13:14
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...
Waldemar Derr
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.524 Beiträge
 
Delphi 12 Athens
 
#2

AW: Jpeg Speicherleck?

  Alt 26. Apr 2011, 13:24
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.
Ein Therapeut entspricht 1024 Gigapeut.
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer
Online

Registriert seit: 13. Aug 2002
17.230 Beiträge
 
Delphi 10.4 Sydney
 
#3

AW: Jpeg Speicherleck?

  Alt 26. Apr 2011, 14:05
... 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.

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.

... 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.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
WladiD

Registriert seit: 27. Jan 2006
Ort: Celle
146 Beiträge
 
Delphi 11 Alexandria
 
#4

AW: Jpeg Speicherleck?

  Alt 26. Apr 2011, 14:27
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.

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.

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.
Waldemar Derr
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:50 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz