Delphi-PRAXiS - Error 223

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)

- - Error 223 (https://www.delphipraxis.net/187725-error-223-a.html)

Hallo,

neuerdings erhalte ich die Fehlermeldung Run Time Error 223.
Ich habe nun geschaut was das Bedeutet "Variant array create". Die Fehlerzeile zeigt mir leider nur eine Funktion mit x-Unterfunktionen an und ist daher nicht wirklich aufschlussreich.

Bedeutet diese Fehlermeldung das zuwenig Speicher vorhanden ist? Und wie kann ich das Problem beheben? Wonach muss ich schauen um den Fehler zu finden?

Ich habe in Windows im Taskmanager das Programm beobachtet und der Arbeitsspeicher steigt stetig an.

Bei den ".Creates" habe ich überall ein ".Free". Gibt es noch irgendwelche Dinge die man freigeben muss damit der Arbeitsspeicher nicht mehr wächst?

(Umgebung Lazarus)

LG
Monday

Was der

Fehler bedeutet, steht doch unmißverständlich in der Hilfe: The variant array creation failed. Usually when there is not enough memory.

Wenn ich beispielsweise versuche, in eine Stringlist eine mehrere Gigabyte große Datei einzulesen, würde das ein Out of Memory auslösen, weil ich soviel Speicher gar nicht habe. Zudem stehen 32-Bit-Programmen höchstens 2 GB Ram zur Verfügung, mehr können sie nicht adressieren.

Wo dein Fehler genau auftritt, kannst nur du selbst feststellen, weil sonst keiner deinen Code hat.
Ob es irgendwelche Dinge in deinem Programm gibt, die erzeugt, aber nicht freigegeben werden, kannst ebenfalls nur du selbst feststellen.
Wie wäre es mit Durchsteppen? Auf diese Weise erfährst du womöglich, an welcher Stelle im Code dieser Speicheranstieg beginnt.

Hallo,

unter Delphi benutzt ich FastMM4 zum Erkennen von Speicherlecks.
Lazarus hat doch bestimmt etwas ähnliches ?

Eine kurze Suche:

http://forum.lazarus.freepascal.org/...p?topic=5240.0

und

http://stackoverflow.com/questions/1...pascal-lazarus

Heiko

Vorgehensweise bei Fehlersuche von steigenden Arbeitsspeicher

Danke für die Antworten.

Jetzt habe ich die Lösung gefunden. Ich schreibe das hier mal, falls nachfolgende Sucher gleiches Problem haben.

Problem war ja, dass der Arbeitsspeicher immer mehr wurde und irgendwann kam dann der Error 223 (Zuwenig Speicher).

Ich hatte StringList benutzt und bei jedem .add wird ja was in den Speicher geschrieben. Mit .free gibt man den Speicher wieder frei. Soweit habe ich richtig gedacht.

ABER wenn der Arbeitsspeicher trotzdem weiter ansteigt, hat man entweder ein .free vergessen oder etwas übersehen.

Ich hatte zwar .free in einer Funktion gemacht, hatte aber vorher eine Bedingung

if (x = y) then exit;

Und das .free danach wurde niemals aufgerufen. Besonders dramatisch wird soetwas, wenn man so eine Funktion in einer schleife durchlaufen lässt wie ich es hatte. Weil dann können schnell aus wenigen KB mehrere hundert MB werden.

Deshalb:

Bei .create's nach .free's suchen und zusätzlich nach vorzeitigen "exit" prüfen evtl. auch nach "break"/"continue" u. ä. !!

Bei dynamischen Arrays kann ich mir ein ganz ähnliches Problem vorstellen - bin mir hierüber aber nicht so sicher.

Wenn man das richtig gemacht hat, durfte das Programm je nach Ablauf keinen dauerhaft steigenden Arbeitsspeicher verursachen, wobei Schwankungen nach oben und unten (!) möglich sind.

LG

Zitat:

Zitat von hoika (Beitrag 1325383)

Hallo,

unter Delphi benutzt ich FastMM4 zum Erkennen von Speicherlecks.
Lazarus hat doch bestimmt etwas ähnliches ?

Eine kurze Suche:

http://forum.lazarus.freepascal.org/...p?topic=5240.0

und

http://stackoverflow.com/questions/1...pascal-lazarus

Heiko

Das mit dem Heaptrc habe ich ausprobiert. Puh aber was mir das konkret sagen soll und welche Erkenntnisse ich daraus ziehen kann, weiß ich nicht, hatte mich damit noch nie beschäftigt...

Ich hatte soetwas in der Art bekommen. Allerdings viel länger und soweit ich gesehen habe, haben sich die Abschnitte immer wieder wiederholt:

Code:

			Heap dump by heaptrc unit

110350 memory blocks allocated : 19827548/20238696

77987 memory blocks freed     : 8643622/8963072

32363 unfreed memory blocks : 11183926

True heap size : 14942208 (160 used in System startup)

True free heap : 1140880

Should be : 1595192

Call trace for block $0023FFE0 size 5

  $006DABAF  TZSQLITECAPIPREPAREDSTATEMENT__BINDINPARAMETERS,  line 518 of D:/lazarus/components/ZEOSDBO-7.1.2-stable/src/dbc/ZDbcSqLiteStatement.pas

  $006DB747  TZSQLITECAPIPREPAREDSTATEMENT__EXECUTEUPDATEPREPARED,  line 657 of D:/lazarus/components/ZEOSDBO-7.1.2-stable/src/dbc/ZDbcSqLiteStatement.pas

  $0071026F  TZABSTRACTRODATASET__EXECSQL,  line 1568 of D:/lazarus/components/ZEOSDBO-7.1.2-stable/src/component/ZAbstractRODataset.pas

  $00440FFA  TFORM1__BUTTON1CLICK,  line 184 of unit1.pas

  $005481AE  TCONTROL__CLICK,  line 2711 of ./include/control.inc

  $00563D5F  TBUTTONCONTROL__CLICK,  line 54 of ./include/buttoncontrol.inc

  $0056445F  TCUSTOMBUTTON__CLICK,  line 169 of ./include/buttons.inc

  $00563C7A  TBUTTONCONTROL__WMDEFAULTCLICKED,  line 20 of ./include/buttoncontrol.inc

Call trace for block $05A57288 size 5

  $006DABAF  TZSQLITECAPIPREPAREDSTATEMENT__BINDINPARAMETERS,  line 518 of D:/lazarus/components/ZEOSDBO-7.1.2-stable/src/dbc/ZDbcSqLiteStatement.pas

  $006DB747  TZSQLITECAPIPREPAREDSTATEMENT__EXECUTEUPDATEPREPARED,  line 657 of D:/lazarus/components/ZEOSDBO-7.1.2-stable/src/dbc/ZDbcSqLiteStatement.pas

  $0071026F  TZABSTRACTRODATASET__EXECSQL,  line 1568 of D:/lazarus/components/ZEOSDBO-7.1.2-stable/src/component/ZAbstractRODataset.pas

  $00440FFA  TFORM1__BUTTON1CLICK,  line 184 of unit1.pas

  $005481AE  TCONTROL__CLICK,  line 2711 of ./include/control.inc

  $00563D5F  TBUTTONCONTROL__CLICK,  line 54 of ./include/buttoncontrol.inc

  $0056445F  TCUSTOMBUTTON__CLICK,  line 169 of ./include/buttons.inc

  $00563C7A  TBUTTONCONTROL__WMDEFAULTCLICKED,  line 20 of ./include/buttoncontrol.inc

[...]

Darum nimmt ja auch

Delphi-Quellcode:

			bar := TBar.Create;

try

  if (something)

  then

    Exit;

finally

  bar.Free; // wird IMMER durchlaufen

end;

Was aber so nur bei lokalen Variablen funktioniert ;)

Zitat:

Zitat von DeddyH (Beitrag 1325427)

Was aber so nur bei lokalen Variablen funktioniert ;)

Bei mir funktioniert das auch mit nicht lokalen Variablen. :stupid:

Du willst aber wohl eher auf dangeling pointers raus. ;)

OK, falsch ausgedrückt, ich meinte, dass das nur klappt, wenn die Instanz innerhalb derselben Methode erzeugt und wieder freigegeben werden soll (wo sollte man auch sonst den Ressourcenschutzblock hinsetzen?).

Zitat:

Zitat von Sir Rufo (Beitrag 1325425)

Darum nimmt ja auch

Delphi-Quellcode:

			bar := TBar.Create;

try

  if (something)

  then

    Exit;

finally

  bar.Free; // wird IMMER durchlaufen

end;

Auch beim Exit?? Ich habe das noch nicht probiert. Ich dachte immer finally wird nur durchlaufen bei einem Fehler bzw. grundsätzlich schon wenn es bis zum Ende durchläuft. Und beim Exit wird der rest nicht mehr durchlaufen, auch beim finally?

Nicht finally mit except verwechseln. Ein Except-Block wird nur im Falle einer Exception durchlaufen, ein finally-Block hingegen immer.

Zitat:

Zitat von Monday (Beitrag 1325440)

Und beim Exit wird der rest nicht mehr durchlaufen, auch beim finally?

Der Rest hinter dem finally..end wird nicht durchlaufen, das im finally..end aber schon.

[etwas OT]
Zum finally gab es mal eine längere Diskussion:

http://www.delphipraxis.net/160164-f...ewuenscht.html
[/etwas OT]