ClientDataset Memoryleak

[Koloss]

Mir sind die Clientdataset Bugs in Delphi 2010 bekannt aber auch in Delphi Seattle 10 gibt es Memoryleaks bei Clientdatasets.

Ich habe LogChanges := False eingestellt und wenn ich einen Datensatz lösche und wieder hinzufüge steigt der Speicher.
Wenn ich aber den Datensatz nur editiere bleibt der Speicher gleich.

Das kann man sehr einfach in einen Timer testen und im Windows Task Manager nachschauen.

Mit Logchanges := True und MergeChangeLog das selbe Problem!

[Uwe Raabe]

Das ist jetzt nicht unbedingt ein Memoryleak im eigentlichen Sinne. Der Taskmanager weiß nämlich nichts über den intern vom Delphi Speichermanager verfügbaren Speicher. Kommt denn bei aktiviertem

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := true;

eine entsprechende Meldung?

[Koloss]

Diesen Befehl konnte ich noch gar nicht.

Edit: Auch ohne verursachten Memory leak kommt der gleiche Auszug.

Der Speicher steigt aber kontinuierlich nach oben! Erst mit EmptyDataset ist der Speicher wieder frei.

[Uwe Raabe]

Zitat:

Zitat von Koloss (Beitrag 1334177)

Edit: Auch ohne verursachten Memory leak kommt der gleiche Auszug.

Dann hat die Applikation noch andere Leaks.

Zitat:

Zitat von Koloss (Beitrag 1334177)

Der Speicher steigt aber kontinuierlich nach oben! Erst mit EmptyDataset ist der Speicher wieder frei.

Dann ist es nicht wirklich ein Leak, der Speicher wird ja kontrolliert wieder freigegeben. Vermutlich ist er auch Delphi-intern als verfügbar markiert. Lediglich Windows merkt davon nichts. Der Hinweis, daß ReportMemoryLeaksOnShutdown kein (zusätzliches) Leak erkennt, ist schonmal ein gutes Zeichen.

Ach ja: welche Delphi-Version?

[ventiseis]

Die Delphi-Version steht im ersten Posting: Seattle.

Ich habe ein ähnliches Problem auf StackOverflow beschrieben, aber bisher hat das Internet noch keine Antwort gewusst ;-)

Allerdings bin ich mir nicht sicher, ob es vielleicht auch am internen FastMM liegt, der mit der mit irgendeiner Neuerung nicht zurecht kommt. Verwendet man den FastMM von SourceForge mit FullDebugMode, dann kommt genau keine Meldung mehr.

[Uwe Raabe]

Zitat:

Zitat von ventiseis (Beitrag 1334227)

Die Delphi-Version steht im ersten Posting: Seattle.

In der Tat! Schade, daß man das nicht sehen kann, während man antwortet...

[hoika]

Hallo,
hast du beim externen FastMM4 auch die Inc-Datei entsprechend angepasst?

Heiko

[ventiseis]

Ich würde behaupten: Ja.

[sahimba]

Zitat:

Zitat von Uwe Raabe (Beitrag 1334217)

Der Hinweis, daß ReportMemoryLeaksOnShutdown kein (zusätzliches) Leak erkennt, ist schonmal ein gutes Zeichen

Nicht unbedingt. Sehr oft, und ich debugge gerade an einem solchen Memoryleak in Datasnap (*), wird der Speicher zwar beim Beenden der Applikation freigegeben so dass ReportMemoryLeaksOnShutdown nichts meldet und doch kann die Anwendung ein Problem mit stetig wachsendem Speicher haben.

(*) ...konkret debugge ich nicht mehr sondern habe das Problem eingegrenzt und, auch in Delphi Seattle, ist da ein böser Hund begraben der schon bei einer HelloWorld-Datasnap-Anwendung auftritt.

[Koloss]

Bei mir wird auch der Speicher freigegeben wenn ich das Programm beende.
Auch mit cds.EmptyDataset wird der Speicher freigegegeben, nur eben mit cds.Delete nicht.

Ob ich eben
cds.First
while not cds.EOF
cds.Delete

oder eben

cds.EmptyDataset

schreibe, sollte bei Logchanges = False, das selbe sein.

[Uwe Raabe]

Zitat:

Zitat von Koloss (Beitrag 1334297)

Ob ich eben
cds.First
while not cds.EOF
cds.Delete

oder eben

cds.EmptyDataset

schreibe, sollte bei Logchanges = False, das selbe sein.

Nein, ganz und gar nicht. Bei EmptyDataSet kann das ClientDataSet ganz andere Mechanismen verwenden, als beim Löschen einzelner Sätze (noch dazu von vorne an). Bei jedem Delete werden allenfalls kleine Blöcke freigegeben, während ein EmptyDataSet den gesamten reservierten Puffer auf einmal freigeben kann. Was genau passiert, ist leider tief in den Midas-Sourcen verborgen.

Es ist auch nicht so, daß der vom Taskmanager als verwendet angegebene Speicher nicht doch als freier Speicher vom Memory-Manager verwaltet wird. Erst wenn dieser den Speicher wieder an das Betriebssystem zurückgibt, kann der Taskmanager dieses auch anzeigen.

[Koloss]

MIt dieser Schleife das selbe Problem:

Code:

  cdsTestStarted.Last;
  while not cdsTestStarted.BOF do
    cdsTestStarted.Delete;

War wahrscheinlich eh klar.

Irgendwann sollte der MemoryManager von Delphi das trotzdem zurückmelden oder?

[Koloss]

Gebe es eigentlich ein alternative zum Clientdataset? Natürlich mit den gleichen komfort?

[Uwe Raabe]

Zitat:

Zitat von Koloss (Beitrag 1334327)

Gebe es eigentlich ein alternative zum Clientdataset? Natürlich mit den gleichen komfort?

Kommt drauf an, was du genau brauchst.

[nahpets]

Schau mal, ob da was dabei ist: http://torry.net/pages.php?id=572

Nutze seit Jahren, wenn ich 'ne "Datenbank" ohne SQL, die nur im Arbeitsspeicher existiert, brauche, die KbmMemTable. Ist leistungsfähig, schnell, die Daten können auch in unterschiedlichen Formaten auf die Platte geschrieben und von dort wieder geladen werden.

Sortieren per Index ist möglich, ebenso Filtern, Locate, FindFirst, FindNext...

Benötigt für große Datenmengen natürlich entsprechend Speicher, mir ist allerdings bisher nicht aufgefallen, dass der Speicherbedarf bei der Nutzung irgendwie zunimmt.

Ist 'n Nachkomme von TDataSet und kann daher mit allen datenbanksensitiven Komponenten genutzt werden.

[Bambini]

Zitat:

Zitat von Uwe Raabe (Beitrag 1334172)

Das ist jetzt nicht unbedingt ein Memoryleak im eigentlichen Sinne. Der Taskmanager weiß nämlich nichts über den intern vom Delphi Speichermanager verfügbaren Speicher. Kommt denn bei aktiviertem

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := true;

eine entsprechende Meldung?

Das wird mit FastMM4 Memory Leak reporting wird wohl nicht funktionieren.
Sind die ClientDataSets denn nicht in C oder C++ geschrieben und werden über *.dll bzw *.OBJ eingebunden?
Die haben dann ihren eignen Memory Manager und der Delphi MM kann da nix sehen.

[ventiseis]

Zitat:

Zitat von Bambini (Beitrag 1334347)

Sind die ClientDataSets denn nicht in C oder C++ geschrieben und werden über *.dll bzw *.OBJ eingebunden? Die haben dann ihren eignen Memory Manager und der Delphi MM kann da nix sehen.

Das könnte auch die sporadisch auftretenden Speicherleaks bei

Delphi-Quellcode:

ApplyUpdates

im

Delphi-Quellcode:

TSimpleDateset

erklären, das ja z.T. auch aus einem Clientdataset besteht. Spannender aber wäre die Frage, warum die "Unknown Bytes" erst unter Seattle angezeigt werden und nicht bereits unter XE3.