RTTI Cache tidying


(bnx2012) #1

We have a simple code-first server in Delphi that has a function to return a string constant. A simple test call to this function works fine. The problem is that if we then close the service application, FastMM will often report a memory leak. Typically this is a TRORTTICacheServiceMethod, a unicode string, and a string list. Sometimes multiples of these. Sometimes a TRORTTICacheService too. And sometimes nothing leaks - it is not consistent.I presume that is because these items are being automatically tidied before we close.

Is there a way we can ensure that these items are tidied before the system closes? It would make for a better development experience if we know that leaks are real leaks, and not just a cache that isn’t emptied. Having been a RODL editor person for many years, I’m not too familiar with the inner workings of this part of the system.

(EvgenyK) #2

hmm, I can’t reproduce this issue with simple testcase.
according to code, we destroy TRORTTICache in finalization section of uRORTTIServerSupport.pas

TRORTTICacheServiceMethod was added into TStringList with OwnsObjects = True so it should be destroyed automatically, the same with above TStringList that was added into fServiceMethods with similar options, i.e. OwnsObjects = True

fServiceMethods is destroyed in TRTTICache.Destroy.

can you attach your log file (*_MemoryManager_EventLog.txt) that generated by Fastmm4 for investigation, pls?

(bnx2012) #3

Thanks for the response. I have uploaded the project that has everything - in particular it may be related to using the web page to make the requests. If you run the server and then load the test web page, it fails this way about 50% of the time.
http://localhost:8080/html/Test.html is the URL to test with the EXE provided.

Please assemble this into a normal URL:
http matthew-jones .com/xfer2u / RemObjectTest.zip
I will remove it once resolved.

(bnx2012) #4

(Also, I have checked, but I didn’t get a notification email for your response. Is the notification system working?)

(EvgenyK) #5

don’t worry, we received your email to support@, I’ll process it and will answer

(RemObjects) #6

Thanks, logged as bugs://78083

(RemObjects) #7

bugs://78083 got closed with status fixed.