Programm braucht ständig mehr Speicher - Lazarus unter Raspi

[m.fuchs]

Oh, ich sehe gerade, es gibt ein paar neue Scripts, die waren vor einigen Tagen noch nicht da: http://blog.boberglund.com/

Wo sieht du da neue Scripte ?
Ich sehe da nur fertige fpc-binäris.

FPC and Lazarus installation script for Raspberry Pi2
FPC and Lazarus local installation script for Raspberry Pi3

[Mathias]

Oh, ich sehe gerade, es gibt ein paar neue Scripts, die waren vor einigen Tagen noch nicht da: http://blog.boberglund.com/

Wo sieht du da neue Scripte ?
Ich sehe da nur fertige fpc-binäris.

FPC and Lazarus installation script for Raspberry Pi2
FPC and Lazarus local installation script for Raspberry Pi3

Ich dachte, die beiden seien einer der alten ich ich gerade installiert habe.
Ein bisschen mehr Infos auf der Seite wären sicher hilfreich.

[Timm Thaler]

Nope. Installation script ... 2 ist das Alte, was ich auch auf dem 3er erfolgreich verwendet habe.
Installation script ... 3 ist neu.

Da FCP 3 nicht in den Repos auftaucht, wie bekommt man eigentlich jetzt die aktuelle Version mit dem Bugfix installiert? sudo update + upgrade geht ja dann auch nicht. Einfach das Script nochmal laufen lassen?

[Timm Thaler]

Der Fehler sollte in Lazarus Trunk Revision 53898 behoben sein.

Nope. Hab gerade mit dem Bo Berglund Script für den Pi3 neu compiliert und hab jetzt Lazarus 1.6.2 vom 12.01., FPC 3.0.0, SVN-Revision 53931, arm-linux-gtk 2.

Memleak mit TStaticText startet bei 19MB und ist schon nach wenigen Minuten bei 21MB.

[Timm Thaler]

Jetzt auf Qt4 umgestellt. Ich weiss zwar nicht, was ich da genau getan habe , aber es funktioniert, die IDE hat Qt-Lock und die Programme auch.

Memleak mit TStaticText braucht jetzt zwar 40.1MB, steht aber wie angenagelt.

[Timm Thaler]

Der Fehler sollte in Lazarus Trunk Revision 53898 behoben sein.

Der Fehler besteht auch zwei Jahre später im aktuellen Trunk Lazarus 1.9 / FPC 3.1.1 immer noch. Hab gerade ein unter Windows mit win32 erstelltes Programm mit Statusbar für den Raspberry / Linux ARM mit gtk2 portiert. Da werden sekündlich eingehende Daten in der Statusbar angezeigt und der Speicher läuft innerhalb weniger Stunden um einige zig MB hoch. Kommentiere ich die Zuweisung an statuspanel.Text aus, bleibt der Speicherbedarf konstant.

[Timm Thaler]

Muss das mal präzisieren: Der Fehler tritt auf Linux-ARM nicht mehr auf im TStaticText.

Er ist unter Lazarus 2.0, FPC 3.2 mit GTK2 auf Linux-ARM nach wie vor reproduzierbar indem man eine Statusbar mit einem Panel auf ein Fenster packt, dazu einen Timer und in der Statusbar wechselnden Text anzeigen läßt:

Code: Alles auswählen

procedure Tgui.tim_timerTimer(Sender: TObject);
var
  txt : string;
begin
  cykl += 1;
  If cykl >= 50 then cykl := 1;
  txt := StringOfChar('I', cykl);
  sts_bar.Panels[0].Text := txt;
end;     

Dabei den Speicherbedarf im Taskmanager beobachten, der geht innerhalb weniger Minuten mehrere MB hoch.

[martin_frb]

https://bugs.freepascal.org/view.php?id=34951#c113651

Wenn jemand der das Problem hat, ein valgrind log erstellen koennte....

[Timm Thaler]

Wenn jemand der das Problem hat, ein valgrind log erstellen koennte....

Kannst Du den Effekt denn reproduzieren?

Muss mal den dritten Pi freischaufeln und da einen aktuellen fpc trunk erstellen. Das dauert leider auf dem Raspi immer Stunden und ohne swap auf 1GB gehts auch nicht.

[martin_frb]

Wenn jemand der das Problem hat, ein valgrind log erstellen koennte....

Kannst Du den Effekt denn reproduzieren?

Muss mal den dritten Pi freischaufeln und da einen aktuellen fpc trunk erstellen. Das dauert leider auf dem Raspi immer Stunden und ohne swap auf 1GB gehts auch nicht.

Ich hab im Moment nur Fedora. Und da hab ich das Problem nicht.

Aber valgrind erzeugt meist sehr gute logs (Voraussetzung cmem und alle packages mit dwarf).

[Michl]

Ich kann das Problem unter Linux Mint KDE nachstellen. Habe gtk_statusbar_push (https://developer.gnome.org/gtk2/stable ... usbar.html) in Verdacht, da niemals gtk_statusbar_remove aufgerufen wird, sondern immer nur die Messages weiter nach oben geschoben werden. Allerdings habe ich mal versucht gtk_statusbar_remove_all (ab gtk 2.22 verfügbar) vorher aufzurufen, was die alle Meldungen vom Statusbar Stack entfernen sollte, aber der Speicher wird weiter erhöht.

Leider habe ich zur Zeit ganz andere Baustellen, sodaß ich da erstmal die Finger von lassen muss. @Timm Thaler: Aber vielleicht hast du ja Lust den Fehler zu finden?

gtk2proc.inc:

Code: Alles auswählen

procedure UpdateStatusBarPanel(StatusBar: TObject; Index: integer;  StatusPanelWidget: PGtkWidget);
...
    gtk_statusbar_push(PGTKStatusBar(StatusPanelWidget), ContextID, PGChar(PanelText))

[Timm Thaler]

Aber vielleicht hast du ja Lust den Fehler zu finden?

Dazu bin ich leider zu dumm. Ich habe es immerhin geschafft einen Bugreport zu machen: https://bugs.freepascal.org/view.php?id=34951

[Michl]

Dazu bin ich leider zu dumm. Ich habe es immerhin geschafft einen Bugreport zu machen: https://bugs.freepascal.org/view.php?id=34951

Ach manno, das ist Quatsch, sowas kannst du schaffen! Ich kann auch nur den Code debuggen und mal etwas auskommentieren und schauen, woher das Problem rührt. Das ist nichts Wildes, nur Zeit.

Wie auch immer, ich habe mir eben die Zeit genommen. Es waren zwei Probleme sichtbar. Das erste war das zuvor geschriebene. Das zweite war, daß bei jeder Textänderung immer wieder erneut das Ownerdraw-Event eingehangen wurde. Ist in Lazarus trunk Revision 60250 behoben (außer OwnerDraw, da müsste man den Text selber verwalten, GTK2 ist hier sehr ungünstig designt).