Es stehen nicht genügend Resourcen.....

[creehawk]

Was soll ich davon halten:

'Es stehen nicht genügend Resourcen im System zur Verfügung, um die Operation auszuführen. Schließen Sie einige Fenster und versuchen es erneut.'

Es handelt sich um ein Programm, das XML Dateien verwaltet. Programmgrösse : 58 MB, maximal 400 KB XML Dateien geleichzeitig geöffnet, maximal 3 Formulare gleichzeitig geöffnet.

Vor allem : welche Operation? Das kommt teilweise ohne irgendeine Aktion meinerseits.

Anders: was muss ich da suchen? Was kann das sein? Ich bin ratlos.

creehawk

P.S. es laufen keine anderen Programme.

[peterbelow]

Die Fehlermeldung ist leider meist schlicht daneben, sie zeigt nur, das eine GDI-Funktion (meist irgend eine Operation mit einem TCanvas) fehlgeschlagen ist.

Kannst Du das im Debugger reproduzieren? Arbeitet das Programm eventuell in einem Hintergrundthread mit einem TCanvas, z. B. dem einer TBitmap? Dann nicht vergessen, die Zeichnenoperationen in Canvas.Lock/Unlock "Klammern" einzuschließen, mit einem try finally Block.

[hoika]

Hallo,
ich würde mal FastMM4 "anwerfen".

Könnte ein Speicherleck sein.

[TurboMagic]

Es gibt glaube ich auch andere Tools die Ressourcen Lecks wie GDI Handels erkennen können...

[creehawk]

Moin Moin.

Speicherlecks habe ich mit 2 Tools gesucht, nix zu finden.

Im Programm werden einige Bitmaps/PNG/DDS verarbeitet, insbesondere an einer Stelle : umwandeln einer Bitmap in Base64 für XML Speicherung.

Ich werfe das mal raus, mal sehen.

creehawk

[Redeemer]

Man sieht im Process Explorer die Anzahl der GDI-Handles, so als ersten Schritt.

[Der schöne Günther]

Der normale Windows Taskmanager kann GDI-Objekte, Handles, Threads, Speicher und vieles mehr anzeigen.

Kannst du das Problem denn halbwegs reproduzieren? Das allein wäre schon sehr viel wert.

[creehawk]

Das reproduzieren des Fehlers ist das Problem, dann hätte man ja einen Ansatz. Aber die Messagebox kommt einfach irgendwann - drei Minuten nach dem Start, zwanzig Minuten nach dem Start.
Wir haben hier mehrere Rechner unterschiedlicher Ausstattung. Bei manchen passiert nie was (83%), beim anderen andauernd (7%), beim wieder anderen gelegentlich(10%). Insgesamt 24 Rechner.

Das angeforderte 'Fenster schliessen' bringt nichts, oft wird nur das Hauptformular angezeigt. Zudem : Beenden kann ich das nur alles mit dem Taskmanager und Task beenden.

In der Messagebox wird als Überschrift der Programmname genannt, deshalb gehe ich davon aus an das kommt eben aus dem Programm. Es werden keine Fremdprogramme aufgerufen, DLLs oder ähnliches verwendet.

Jetz werden wir mal den Taskmanager befragen über Handles und das ganze Zeug. Wenn die Meldung kommt müsste ja was zu finden sein.

creehawk

P.S. die Base64 habe ich rausgeworfen, Canvas Aktionen habe ich keine drin.

[Der schöne Günther]

Schau doch noch im Windows-Event-Viewer nach, ich wette da stehen auch mehr Informationen (welcher Prozess, evtl. sogar Adresse aus dem Stack)

[Redeemer]

Ja poste mal den Quelltext, mindestens vom Erstellen der Bitmap bis zum Freigeben.

Wenn GDI überlastet ist, fehlen oft Teile von Fenstern.

[creehawk]

Gefunden. Hoffentlich. Jedenfalls ist der Fehler die letzten 90 Minuten auf mehreren Rechnern nicht mehr aufgetaucht.

Um eine Bitmap umzuwandeln in Base64 verwenden wir IdEncoderMIME (Indy). Schön. Allerdings fehlte in der Funktion eine Kleinigkeit.

ALT:

Delphi-Quellcode:

function CreateBase64String(FileName: String): String;
var
  FS: TFileStream;
begin
  FS := TFileStream.Create(FileName, fmOpenRead);
  try
    Result := TIdEncoderMIME.EncodeStream(FS);
  finally
  end;
end;

NEU:

Delphi-Quellcode:

function CreateBase64String(FileName: String): String;
var
  FS: TFileStream;
begin
  FS := TFileStream.Create(FileName, fmOpenRead);
  try
    Result := TIdEncoderMIME.EncodeStream(FS);
  finally
    FS.Free;
  end;
end;

Gesehen? Da habe ich auch mehrfach drüber weggelesen.

Na, vielen Dank für die Hinweise, ich hoffe das war es. Wenn nicht.....

creehawk

[Der schöne Günther]

Dann würde ich aber sagen dass deine zwei Tools die du verwendet hast nicht gut sind:

Zitat:

Zitat von creehawk (Beitrag 1505633)

Speicherlecks habe ich mit 2 Tools gesucht, nix zu finden.

[Redeemer]

Warum braucht man eigentlich Tools dafür? ReportMemoryLeaksOnShutdown reicht doch, wobei es bei manchen kleinen Typen manchmal erst ab einer gewissen (kleinen) Zahl so etwas meldet.

[Rolf Frei]

Ja mit den Bordmittel und ReportMemoryLeaksOnShutdown=True habe ich bisher immer alle Memoryleaks gefunden. Da braucht es keine zusätzlichen Tools. Das hätte auch in diesem Fall zu 100% eine grosse Anzahl nicht freigegebener TFileStreams gemeldet.

[venice2]

Zitat:

Zitat von Redeemer (Beitrag 1505677)

Warum braucht man eigentlich Tools dafür? ReportMemoryLeaksOnShutdown reicht doch, wobei es bei manchen kleinen Typen manchmal erst ab einer gewissen (kleinen) Zahl so etwas meldet.

Es reicht eben nicht.
Verwende immer ReportMemoryLeaksOnShutdown trotzdem wurde in einen meiner Projekte nicht erkannt das ein Handle nicht freigegeben wurde.
Ich konnte aber erkennen das im Task Manager sich die Handles summierten.

[Rolf Frei]

Ja aber das hat nichts mit Memoryleaks zu tun. Für solche Sachen wie Handles, braucht man schon etwas anderes. Das ist nicht Aufgabe des Memorymanagers.

[creehawk]

Moin Moin!

Wie ich oben geschrieben habe passiert jetzt nichts mehr. Ob das jetzt ein MemoryLeak war weiß ich nicht. @redemeer's Hinweis auf ReportMemoryLeaksOnShutdown haben wir natürlich auch verwendet - nix.

Als wir allerdings die Base64 Kiste wieder aktiviert haben : nach einer Weile tauchte die Meldung dann wieder auf.

Nun haben wir eine Timerfunktion am laufen, die regelmäßig eine Prüfung vornimmt. Base64 dringelassen, Timer rausgenommen. Jetzt kommt die Meldung auch nicht mehr.

Delphi-Quellcode:

  if TDirectory.exists(ModPath + '[ShipEdit] Segelweberei Enbesa') = true then
  begin
    ShipYardForm03.SailClothingEnbesaImage.Picture.Graphic :=  MainForm.ImageCollection.GetScaledImage(MainForm.ImageCollection.GetIndexByName('ja'),48,48);
  end
  else
  begin
    ShipYardForm03.SailClothingEnbesaImage.Picture.Graphic := MainForm.ImageCollection.GetScaledImage(MainForm.ImageCollection.GetIndexByName('nein'),48,48);
  end;

Aber was das jetzt mit der Meldung zu tun hat? Mit Base64 hat das allerdings nix zu tun, sind PNG Grafiken.

Kurios.

creehawk

[haentschman]

Moin...8-)
[Klugscheiß ON]

Delphi-Quellcode:

if TDirectory.exists(ModPath + '[ShipEdit] Segelweberei Enbesa') = true then

..niemals auf True prüfen. :warn:

Delphi-Quellcode:

if TDirectory.exists(ModPath + '[ShipEdit] Segelweberei Enbesa') then

...
[Klugscheiß OFF]
:zwinker:

[Blup]

Du hast die Freigabe der skalierten Grafik vergessen.
Wenn ReportMemoryLeaksOnShutdown in deiner Anwendung auf True gesetzt ist, wird dieser Speicherfehler beim Beenden der Anwendung auf jeden Fall gemeldet.

Delphi-Quellcode:

var
  sImage: string;
  lImage: TWICImage;
begin


  if TDirectory.exists(ModPath + '[ShipEdit] Segelweberei Enbesa') then
    sImage := 'ja'
  else
    sImage := 'nein';

  {gibt ein Image der Collection zurück, für die Freigabe ist die Collection verantwortlich}
  lImage := MainForm.ImageCollection.GetIndexByName(sImage);
  {erzeugt ein neues Image der gewünschten Größe, für die Freigabe ist man selbst verantwortlich!}
  lImage := MainForm.ImageCollection.GetScaledImage(lImage, 48, 48);
  try
    {ezeugt intern eine Kopie des Image per Assign()}
    ShipYardForm03.SailClothingEnbesaImage.Picture.Graphic := lImage;
  fianlly
    lImage.Free;
  end;

[creehawk]

@haentschman
Okay. Wo finde ich die Erklärung warum nicht? Für mich war des jetzt logisch so abzufragen. Und das mache ich anderweitig auch. Gilt das für alle Elemente?

@Blup
Okay, wusste ich jetzt so nicht....
Danke, wird getestet.

creehawk

[haentschman]

Hallöle...8-)

Zitat:

Der Vergleich "BoolVar=True" kann sogar kräftig in die Hose gehen!
Bei einem normalen Boolean ist es so, daß "True" den Ordinalwert "1" hat. Bei ByteBool, WordBool und LongBool hat "True" normalerweise den Ordinalwert "-1".

Lesestoff:
https://www.delphipraxis.net/57121-u...t-boolean.html