[gelöst] Lazarus Trunk TAChart Memoryleak

[Michl]

Hallo wp,

neues Problem mit dem TAChart. Ich habe zwar noch Lazarus Rev 49740 und nicht die allerletzte Trunk-Version, hier aber das Problem, dass das TChart nicht richtig aufgeräumt wird.

Einfach ein neues Projekt erstellen und ein TChart auf dem Formular ablegen, Heaptrc einschalten, Projekt starten und wieder beenden -> Heaptrc meldet 3 Memoryleaks.

Ich werde morgen mal die letzte Trunc-Version probieren.

Viele Grüße

Michael

[wp_xyz]

Kann ich nicht reproduzieren.

[Michl]

Ich habe etappenweise Lazarus Revision 49757 bis 49000 getestet, immer mit dem gleichen Memoryleak. Da die Revision 49524 für Lazarus 1.4.2 genutzt wurde und ich diese Version mit FPC 2.6.4 hier habe und dort kein Memoryleak ist, ist der Bug mMn in FreePascal zu suchen.
Komischerweise sind die 32 und 64bit-Version von FreePascal (Windows7) betroffen:
FreePascal 32bit Revision 31434
FreePascal 64bit Revision 31486

Auf meinem Notebook habe ich noch die 32bit FreePascalversion Rev. 31299 mit Lazarus Rev. 49609 rumliegen, dort gibt es den Memoryleak noch nicht.

Folgende Meldung kommt von Heaptrc:

Code: Alles auswählen

Heap dump by heaptrc unit
2320 memory blocks allocated : 178528/184976
2317 memory blocks freed     : 178284/184728
3 unfreed memory blocks : 244
True heap size : 327680 (112 used in System startup)
True free heap : 327088
Should be : 327128
Call trace for block $0347F9F8 size 124
  $0049B38C  TRASTERIMAGE__CREATE,  line 277 of ./include/rasterimage.inc
  $0049C84F  TCUSTOMBITMAP__CREATE,  line 52 of ./include/custombitmap.inc
  $005E6A3E  TCANVASDRAWER__CREATE,  line 127 of tadrawercanvas.pas
  $005B2082  TCHARTGUICONNECTORCANVAS__CREATEDRAWER,  line 74 of taguiconnector.
pas
  $005A2D24  TCHART__CREATE,  line 290 of tagraph.pas
  $0043BE0D
  $0043C311
Call trace for block $03405DA8 size 72
  $005E6A3E  TCANVASDRAWER__CREATE,  line 127 of tadrawercanvas.pas
  $005B2082  TCHARTGUICONNECTORCANVAS__CREATEDRAWER,  line 74 of taguiconnector.
pas
  $005A2D24  TCHART__CREATE,  line 290 of tagraph.pas
  $0043BE0D
  $0043C311
  $004371CB
  $0043D5A3
Call trace for block $0340D710 size 48
  $005B2082  TCHARTGUICONNECTORCANVAS__CREATEDRAWER,  line 74 of taguiconnector.
pas
  $005A2D24  TCHART__CREATE,  line 290 of tagraph.pas
  $0043BE0D
  $0043C311
  $004371CB
  $0043D5A3
  $004B553F  INITCOMPONENT,  line 3135 of lresources.pp

Testprojekt anbei.

Leider dauert es sehr lange, wenn ich Lazarus und Freepascal neu bauen muss und kann, da ich heute wenig Zeit habe, die genaue Revision von Freepscal evtl. heute nicht ausfindig machen.

Soweit erstmal das Update. Ich werde den Fehler, wenn ich ihn lokalisiert habe (und er nicht möglicherweise schon behoben wurde) im Bugtracker melden, da es ja ein Fehler von FreePascal (TRasterImage) und nicht deinem Baby ist.

Bis dahin

Michael

[Edit]
Lazarus 1.5 Rev 49758 FPC 3.1.1 Rev 31522 i386-win32-win32/win64 hat den Bug noch drin

[wp_xyz]

Danke, dass du dich darum kümmerst.

Falls du die fehlerhafte FPC-Version näher einkreisen kannst, würde ich dich bitten, auch ein normales Bitmap zu testen. In der letzten TAChart-Zeile, die im HeapTrace aufgeführt ist, wird ein Buffer-Bitmap erzeugt, das aber im Destroy wieder sauber zerstört und auch nirgendwo mehr neu erzeugt wird. Wenn aber man den Heaptrace weiter verfolgt, fällt mir TRasterImage.Create auf, wo einiges erzeugt, allerdings - in meiner, nicht problembehafteten Version - auch wieder zerstört wird. Aber vielleicht stimmt da etwas mit der Referenzzählung nicht. Es wäre dringlicher, wenn das Problem schon an einem Standard-Bitmap auftritt, als nur bei dem etwas elitären TAChart.

[Michl]

Falls du die fehlerhafte FPC-Version näher einkreisen kannst, würde ich dich bitten, auch ein normales Bitmap zu testen.

Meinst du sowas?!

Code: Alles auswählen

procedure TForm1.FormCreate(Sender: TObject);
begin
  MachFoto;
end;
 
procedure TForm1.MachFoto;
var
  ScreenDC: HDC;
  Dummy: TBitmap;
begin
  Dummy := TBitmap.Create;
  try
    ScreenDC := GetDC(0);
    Dummy.LoadFromDevice(ScreenDC);
    Image1.Picture.Bitmap.Width  := Dummy.Width;
    Image1.Picture.Bitmap.Height := Dummy.Height;
    Image1.Picture.Bitmap.Canvas.StretchDraw(Image1.ClientRect, Dummy);
  finally
    ReleaseDC(0, ScreenDC);
    Dummy.Free;
  end;
end; 

Das macht keine Probleme!

Ich habe mir jetzt mein eigenes kleines FPCUp geschrieben und bin gerade am Revisionen testen - dauert nur ein bischen

[Michl]

Habe die Revision gefunden, die diese Probleme mit sich bringt. Es ist die FPC-Revision 31328, eine Änderung am Compiler:

Code: Alles auswählen

  * guarantee the order of parameter pushes again after r31201 on platforms
    that don't use a fixed stack (mantis #28454)
   o moved the code to finalise managed out parameters from ncgcal to ncal,
     and add it to the init code of the call node (so it's evaluated before
     any parameters are processed, ensuring that mantis #28390 stays fixed)

Ich habe es auch im Bugtracker gemeldet: http://bugs.freepascal.org/view.php?id=28628

[wp_xyz]

Danke. Ich hoffe, dass die fpc-Spezialisten damit weiterkommen und wegen des Titels nicht denken "TAChart? Geht mich nix an". Wir werden sehen...

Könntest du dein mini-fpcup-Skript hier posten? Mit dem "großen" fpcup habe ich immer wieder Probleme.

[af0815]

Könntest du dein mini-fpcup-Skript hier posten? Mit dem "großen" fpcup habe ich immer wieder Probleme.

Neuer Thread ev. sinnvoll ?!

[Michl]

Könntest du dein mini-fpcup-Skript hier posten? Mit dem "großen" fpcup habe ich immer wieder Probleme.

Neuer Thread ev. sinnvoll ?!

Habe ich gemacht: http://www.lazarusforum.de/viewtopic.php?p=79582#p79582

PS: Mein kleines Programm um Revisionen zu testen, kann ich, wenn gewünscht, auch noch posten, müsste es zuvor aber noch ein bischen aufräumen

[Michl]

Ich hoffe, dass die fpc-Spezialisten damit weiterkommen und wegen des Titels nicht denken "TAChart? Geht mich nix an". Wir werden sehen...

Wahrscheinlich hätte ich einen besseren Titel wählen können, leider tritt dieses Verhalten soweit ich das testen konnte nur beim TChart auf.

Während der Constructor TCanvasDrawer.Create (unit TADrawerCanvas) aufgerufen wird, wird der Destructor TCanvasDrawer.Destroy nicht mehr aufgerufen.

[wp_xyz]

Ich hoffe, dass die fpc-Spezialisten damit weiterkommen und wegen des Titels nicht denken "TAChart? Geht mich nix an". Wir werden sehen...

Wahrscheinlich hätte ich einen besseren Titel wählen können, leider tritt dieses Verhalten soweit ich das testen konnte nur beim TChart auf.

Sorry, das war nicht als Kritik gemeint.

[Michl]

Alles gut! Ich konnte das Problem schon auf ein Minimalbsp (1 Unit) reduzieren, werde es sobald ich genaueres weiss hier posten und wenn nötig einen neuen Bugreport aufmachen.

[wp_xyz]

Ich hab mir jetzt auch einen aktuellen fpc-trunk gebaut und kann das Problem reproduzieren. Es ist wie du schreibst, dass mit dem aktuellen trunk-fpc der Destructor von TCanvasDrawer nicht aufgerufen wird, mit fpc2.6.4 dagegen schon. Das muss etwas mit der Referenzzählung zu tun haben.

[Michl]

Ich habe nun einen neuen Bugreport erstellt, da das Verhalten definitiv nicht am TChart liegt: http://bugs.freepascal.org/view.php?id=28632

Wen es interessiert, anbei das Minimierte Bsp, was beim TChart für quer läuft.

[wp_xyz]

Gutes Beispiel. Vor allem auch, weil es zeigt, wie man durch Reduzieren ein Problem einkreisen kann.