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