Systemressourcen erschöpft

[stahli]

Hi,

ich habe eine komplexe Anwendung geschrieben (Turniersoftware) die zur Laufzeit dynamisch tausende Komponenten erzeugt (Spiele, Spieler, Satzergebnisse, Zeittafeln etc.), die Daten anzeigen und Bearbeitungen ermöglichen.

Im Moment gebe ich damit testweise ältere umfangreiche Turnierdaten eines großen Mannschaftsturniers ein und erhalte neuerdings immer wieder die Meldung "Systemressourcen erschöpft".

Kann mir jemand bei einem Lösungsansatz helfen? Im Moment habe ich noch keine wirkliche Idee woran das liegen kann :-(

Die Anzahl der Handels schwankt immer etwas und war auch schon höher als zum Zeitpunkt der Fehlermeldung.
Evtl. hat das Problem auch mit einer Speicherfunktion auf die Festplatte zu tun...

Anbei zwei Screenshots des Systemmonitors.

Kann mir jemand einen Tip geben? Muss ich erzeugte Komponenten auf verdeckten Registerseiten oder nicht benötigte Formulare gleich wieder auflösen?

Danke
Stahli

[Luckie]

Gibst du auchnicht mehr bentugte Objekte auch wieder frei? Dies gilt auf für GDI Ressourcen.

[stahli]

Hmm, das kann ich schwer beantworten...

Ein Turnierprojekt ist so etwas ähnliches wie eine DFM. Die TUR-Datei wird geladen und die (massenweise) enthaltenen Datenkomponenten werden erzeugt und geladen.

Dann gibt es verschiedene sichtbare Komponenten, z.B. Designer und Listen, denen die Datenkomponenten zugewiesen werden. Diese erzeugen dann eine passende Anzahl sichbarer Komponenten, die die Daten anzeigen (siehe z.B. Spielerlisten im Bild).

Werden die Daten aufgelöst, werden auch "automatisch" die sichtbaren Komponenten entfernt. Das findet aber nicht statt, solange ich nur ein anderes Register oder Unterformular auswähle.

Wenn die Anzahl der gleichzeitig erzeugten Komponenten das Problem sein sollt könnte ich vielleicht wenigstens nicht gebrauchte Unterformulare auflösen oder Inhalte von ausgeblendeten Registern löschen...
Aber erst einmal würde ich gern genau wissen, wo das Problem genau steckt und wie ich eine "drohende Ressourcenüberschreitung" vielleicht vorher erkennen kann...
-> "Bitte schnell alles speichern, gleich knallts!" - oder so :-(


Und GDI-Ressourcen kann ich im Moment noch nicht recht einordnen. Ach so, jeder Spieler verwaltet aicuh noch ein Bitmap.


Dannke schon mal!

[Dunkel]

Zitat:

Zitat von stahli

Und GDI-Ressourcen kann ich im Moment noch nicht recht einordnen. Ach so, jeder Spieler verwaltet aicuh noch ein Bitmap.

Genau solche Bitmaps sind/beinhalten GDI-Ressourcen.

Hast Du schon mal FastMM (oder ähnliche Speicher-Profiler) mitlaufen lassen? Anhand deren Log kann man recht gut herausfinden, wo was nicht freigegeben wird.

[stahli]

Nein, da habe ich mich noch nicht heran getraut.
Aber da muss ich dann wohl mal durch und sehen, ob ich damit zurecht komme...

[Net7]

Zitat:

Zitat von stahli

Dann gibt es verschiedene sichtbare Komponenten, z.B. Designer und Listen, denen die Datenkomponenten zugewiesen werden. Diese erzeugen dann eine passende Anzahl sichbarer Komponenten, die die Daten anzeigen (siehe z.B. Spielerlisten im Bild).

Werden die Daten aufgelöst, werden auch "automatisch" die sichtbaren Komponenten entfernt. Das findet aber nicht statt, solange ich nur ein anderes Register oder Unterformular auswähle.

Wenn die Anzahl der gleichzeitig erzeugten Komponenten das Problem sein sollt könnte ich vielleicht wenigstens nicht gebrauchte Unterformulare auflösen oder Inhalte von ausgeblendeten Registern löschen...
Aber erst einmal würde ich gern genau wissen, wo das Problem genau steckt und wie ich eine "drohende Ressourcenüberschreitung" vielleicht vorher erkennen kann...
-> "Bitte schnell alles speichern, gleich knallts!" - oder so :-(

Wie erstellst du zb. die Strings oder Interger-Werte, zur Ansicht deiner Daten? Local oder Global? Ich hatte mal ein ähnliches Problem. Die Aufgabe meines Programm damals war, die Auswertung von ca. 160000 Zeilen IP-Ländercounts. Bei der Vergabe von zb. Stringlists auf localer Ebene hatte ich irgendwann auch Ressourcenmangel. Auf globaler Ebene nicht mehr.

Mfg Net7

[mjustin]

Zitat:

Zitat von stahli

Kann mir jemand einen Tip geben? Muss ich erzeugte Komponenten auf verdeckten Registerseiten oder nicht benötigte Formulare gleich wieder auflösen?

Um eventuelle Memory Leaks zu erkennen, kann man (afaik bei Delphi 2006 und höher) in der dpr Datei diese Zeilen einfügen. Dann wird eine Zusammenfassung beim Programmende angezeigt.

Delphi-Quellcode:

{$WARN SYMBOL_PLATFORM OFF}
   ReportMemoryLeaksOnShutDown := DebugHook <> 0;
{$WARN SYMBOL_PLATFORM ON}

Falls eine große Zahl nicht freigegebener Objekte angezeigt wird, kann man anhand der angezeigten Klassennamen versuchen, die Ursachen zu finden. Für detailliertere Fehlerprotokolle kann man FastMM4 direkt einbinden und die Codestellen automatisch auflisten lassen, an denen Objekte erzeugt wurden, die nicht freigegeben werden.

[stahli]

@Net7:
Die Daten sind vorwiegend als Eigenschaften in Objekten enthalten.

@mjustin:
Danke! D2006 bringt da ja schon einen eigenen Ansatz mit (siehe Bild).
Ich hätte nicht gedacht, dass mein Problem doch selbst gemacht ist - muss erst mal aufräumen!
Zumindest ist ein Lösung in Aussicht :-)

Verstehe ich das richtig, dass FastMM oder EurekaLog dann darüber hinaus "nur" helfen, die Stelle im Quelltext leichter zu finden?


Danke schon mal für die GRO?E Hilfe!

Stahli

[himitsu]

Systemressourcen sind aber kein Speicher (im MemoryManager),

aber die ganzen GDI-Objecte, welche z.B. in einem TBitMap gekapselt sind schon.

Wobei ~780 Bilder doch eigentlich nicht viel sind (dürften doch nicht viel mehr als 800 bis 4000 GDI-Objecte drin stecken :gruebel: und ich dachte soviel bekommt windows noch locker hin)

[jaenicke]

Zitat:

Zitat von stahli

Danke! D2006 bringt da ja schon einen eigenen Ansatz mit (siehe Bild).
Ich hätte nicht gedacht, dass mein Problem doch selbst gemacht ist - muss erst mal aufräumen!

Oh ja, bei über 700 nicht aufgeräumten Bitmaps und Bitmapimages musst du dich nicht wundern, wenn die Systemressourcen irgendwann erschöpft sind. ;-)

Zitat:

Zitat von stahli

Verstehe ich das richtig, dass FastMM oder EurekaLog dann darüber hinaus "nur" helfen, die Stelle im Quelltext leichter zu finden?

Richtig. Die zeigen dir an wo die entsprechenden Objekte erstellt wurden.

Aber das siehst du ja vielleicht auch selbst bei dir. Entscheidend könnte z.B. sein, wenn du TBitmap castest um es irgendwo als Pointer zu speichern. Denn dabei geht ggf. der Referenzzähler flöten und es wird nicht mehr aufgeräumt.
Das wären neben den Standardfehlern weitere Fallstricke.

// EDIT:

Zitat:

Zitat von himitsu

aber ~780 ist doch eigentlich nicht viel (dürften doch nicht viel mehr als 4000 GDI-Objecte drin stecken :gruebel: und ich dachte soviel bekommt windows noch locker hin)

Naja, das werden ja ggf. noch mehr, wenn das Programm länger läuft. ;-)