Fehler mit externer DLL, Callback-Funktionen.

[Rainer Wolff]

Zitat von shebang:

ReportMemoryLeaksOnShutdown := True hast du bereits gesetzt?

Schon lange, wobei ich zugebe, einige Leaks bisher großzügig ignoriert zu haben, da mir wurst war, ob ein paar Delphi-Objekte vielleicht zu viel Speicher belegen.
Den Fehler würde ich eher zwischen DLL und Delphi vermuten, da erzählt ReportMemoryLeaks meiner Ansicht nach nicht genug, vielleicht kenne ich mich da aber auch zu schlecht aus.

Inzwischen habe ich FastMM4 an den Start gebracht, auch ein paar Delphi-Leaks aufgeräumt und jetzt ein neues Problem an ganz anderer Stelle:

Meine Berechnungen, die Spring4d intensiv benutzen (inkl. ORM), liefern Schrott, wenn ich die FastMM4-Unit einbinde.

[jaenicke]

Zitat von Rainer Wolff:

Meine Berechnungen, die Spring4d intensiv benutzen (inkl. ORM), liefern Schrott, wenn ich die FastMM4-Unit einbinde.

Das kann (!) darauf hindeuten, dass im Speicher etwas richtig schief geht, was auch die anderen Probleme erklären würde. Denn FastMM überschreibt ungültigen Speicher teilweise, so dass z.B. Zugriffe auf Speicherbereiche schon freigegebener Objekte nicht mehr die (vorher noch vorhandenen und nur als gelöscht markierten) Werte liefern.
Außerdem ist das Speicherlayout bei einem anderen Speichermanager anders, so dass auch dadurch vorher verdeckte Probleme Wirkung zeigen können.

Aber gerade bei solchen unspezifischen Problemen gibt es sehr viele mögliche Ursachen, was dir vermutlich auch klar ist. Das geht bei simplen Sachen los wie falsche Aufrufkonventionen, die du sicherlich aber schon geprüft hast.

Wenn man Speicherstellen identifizieren kann, die offenbar später falsche Werte bekommen, sind z.B. Datenhaltepunkte eine Möglichkeit um die Änderung mitzubekommen. Von außen ist es aber schwer konkrete Tipps zu geben.

[Rainer Wolff]

Zitat von jaenicke:

Zitat von Rainer Wolff:

Meine Berechnungen, die Spring4d intensiv benutzen (inkl. ORM), liefern Schrott, wenn ich die FastMM4-Unit einbinde.

Das kann (!) darauf hindeuten, dass im Speicher etwas richtig schief geht, was auch die anderen Probleme erklären würde. Denn FastMM überschreibt ungültigen Speicher teilweise, so dass z.B. Zugriffe auf Speicherbereiche schon freigegebener Objekte nicht mehr die (vorher noch vorhandenen und nur als gelöscht markierten) Werte liefern.
Außerdem ist das Speicherlayout bei einem anderen Speichermanager anders, so dass auch dadurch vorher verdeckte Probleme Wirkung zeigen können.

ok, das war mein eigener Bockmist (nicht initialisierter Funktionsrückgabewert), erstaunlich, dass das erst jetzt herauskommt