Hello,
I am interested to find out if there is any software that I can use to find any memory leaks in my xojo application.
Thanks
Instruments from Apple comes included with Xcode.
or submerge it in a tank of water and look for bubbles
2 Likes
If itÂs an object leak due to a reference not getting cleared or a circular reference not getting broken then you can use this little snippet to walk all the objects that the framework knows about and see if the counts are going up. If itÂs something else that youÂre allocating and not disposing of then this wont help. I use this in a temporary window with nothing but a button to run it and a text area to place the output in. Run it periodically and see if you have more of any kind of object than you expect to.
This code predates the array.sortwith() functionality so I sort the 2 arrays together by concatenating them into a string in a string sortable format 
Were I to do that today it wouldnÂt be necessary. It also predates the ENDOFLINE functionality Boy⊠this is old I did just use it the other day to find a problem though, so it still works!
Last line puts the output into textArea1 which obviously will error unless you have someplace to put it.
dim d as Dictionary
dim i, count as Integer
dim s, out as string
dim SortArray(0) as string
dim cr as string = chr(13) + chr(10)
count = Runtime.ObjectCount - 1
out = "Object Count: " + str( count+1) + cr
out=out+ "Memory Used: " + format( Runtime.MemoryUsed, â#,â) + cr + cr
d = new Dictionary
for i = 0 to count
s = Runtime.ObjectClass( i)
if d.HasKey( s) then
d.value( s) = d.Value( s) + 1
else
d.Value( s) = 1
end if
next
count = d.Count - 1
Redim SortArray( count)
for i = 0 to count
SortArray( i) = Format( d.Value( d.Key( i)), â000000â) + â:â + d.Key( i)
next
SortArray.Sort
for i = 0 to count
out = out + NthField( SortArray( i), â:â, 1) + " " + NthField( SortArray( i), â:â, 2) + cr
next
TextArea1.AppendText( out)
if you have object with parent -> child relation ship, you may want to make sure that any child holding a reference to a parent uses a weak reference for that.
or that you specifically break the parent child relationship when youÂre cleaning up the objects. The trap is doing it in the destructor. The destructor wont get called until all the references are gone, which they wont ever be if youÂre using the destructor to break them.
back before weak references we just created a close or cleanup method that broke any such things
But just cleaning up you own code does not mean that there will be no leaks. The Xojo framework itself has leaks⊠finding them is difficult and fixing them might be impossibleâŠ
If on Windows, you can try this quick & dirty method:
Open Task Manager
Switch to Details tab (on Windows 10 - it may be called something different on older versions)
Right-click the column headings and turn on
Handles
Threads
User Objects
GDI ObjectsRun your app and watch the #s.
In the case when your Xojo objects are not leaking, but the framework (or a third party plugin) is leaking Windows OS objects, you may catch it.
The last time I used that method to search for a memory leak, I almost drowned.
For a rough test: When I finished a class and have tested it enough to believe it could be fairly ok, I usually create a simple test window with a button that creates instances of this class in a loop, modify these instancesâ properties that deliver classes themselves and watch Activity Monitor for the RAM consumption of the app while I click the button repeatedly and then pause to see if memory is released.
For testdriving declared classes, I have a debug boolean that when enabled spills out debug information in the classesâ destructor including the ARC count.
Instruments has come a long way, itâs much easier to figure out what youâre leaking and also the stack of the leaking object.
Iâm using it at the moment to resolve some CoreGraphics & CoreImage issues.
Instruments rocks - in fact Iâll plug my own feedback report to show how it can not only tell you what was leaked, but (da dum!) who leaked it: <https://xojo.com/issue/34107> See the screenshots especially the âFeedback-000001.pngâ one which shows how Instruments shows you the Library and Method name that leaked the object. Smoking gun 
resurrecting an old thread sorry. But instruments doesnÂt always show you anything useful at all. Right now IÂm looking at an app that instruments says leaks something different every time and sometimes not leaking even though memory usage is constantly increasing. Right now IÂm looking at hundreds of 96 byte Â__NSCFString being leaked each 10 second testing interval. This morning it was core image structures being leaked, but no more. Just a recompile and itÂs something different now. Yet the app is definitely leaking. For my current NSCFStrings leaking the responsible library and Frame are completely blank. Though it has gathered the data that was leaked but no stack trace. The data however is in hex in a window where I canÂt highlight and copy it to try to see if it has anything recognizable in it.
I am so sick of memory leaks in code I didnÂt write right now. whats a few hundred meg lost? Just make sure youÂre compiled to 64 bit so you can keep leaking memory for months and it will happily swap it out.
I think IÂm taking the weekend off and not going to look at a single line of code, thats how pissed off I am at leaking a hundred meg in an afternoon with absolutely no information form instruments that I can use and no increase in my own object counts so itÂs not my fault.
From what I can gather Xcode has some new shiny tools built-in, so it could be that theyâre letting Instruments fall to the way side; just like Quartz Composer 
Well, I can normally only track leaks which create thousands of objects and leak a couple of megabytes.
All those small leaks of a few bytes are nearly impossible to locate.
BTW, I found the Runtime object iterator utterly useless because it includes its own objects it creates. I had also tried to write smart code that would use introspection to check an object and all its dependencies for a circular reference, but that also fails once you run into items with arrays, because Introspection, or rather the Variant type, doesnât let you access the elements if you donât hard-code the correct array element type for them. There used to be an actually useful function in the early days called DebugDumpObjects, but that got removed in the wrong belief that the new Runtime module could replace it and be better at it, when in fact it got worse. Sad story that never seemed to interest anyone at Real after breaking it (in fact, at that time I worked for them and tried to get it working again but was kicked out before I could finish it).
James, is your app using HTMLViewers or any other plug-ins? Javascript and other Cocoa code may be garbage-collected rather than reference-counted, in which case you will see what appears to be âleaksâ but which are actually just garbage building up, which will be eventually collected. I spent a number of hours tracking âleaksâ in HTMLViewer/JavaScript code which turned out to be not a leak.
I donât think modern Cocoa does Garbage collection anymore, something to do with cuts to local governments⊠Although donât hold me to it as some API uses âlazyâ reference counting. Which means that the memory gets released whenever the OS deems necessary, sounds a lot like Garbage Collection to me!
Lazy APIs are a PITA, not just for leak checking, but also when working with the App Sandbox, as it may not load the file contents when your application has access to the file.