Destructor = Clean memory?

My Linux build has leaks that do not show up on my Mac. Can I simply rule out all the stuff that’s being destructed automatically?

Could a Xojo bug in theory still lock memory from a class when the destructor is called automatically?

If you got circular references then that will not resolve it self without you braking the circular reference when your ready to get rid of the objects involved.

Add a Destructor to the classes that you are suspect of leaking. Add a break as code. If you don’t get the break then you know that the Destructor doesn’t fire.

I was under the impression the destructor won’t fire automatically if I still have a circular reference. Also, the exact same scenario works fine on my Mac.

I already know it fires, hence the question ‘can I forget about that part or could Xojo still hold on to something regardless’.

If Xojo is holding onto it after its Destructor fires, you should consider that a memory leak and a bug.

Then I’ll probably have to go in deep. :frowning:

Arthur - in case you missed it. This may be of help:

It’s been a long time, so things may well have changed, but this is how destructors worked when I originally added them to the language: after the last remaining reference to an object was released, the runtime would invoke the object’s Destructor method. Calling this method creates a new temporary reference, in the form of the destructor’s “self” variable; so it is possible for the destructor to resurrect its object, by storing “self” somewhere permanent. Any instance method the destructor calls also has access to “self”, so it’s not just the destructor that can keep the object alive.

After the “Destructor” method has returned, the runtime checks again: is the reference count back to zero? If so, the object’s memory will be released. Otherwise, it is left alone to go about its business.

It is therefore possible for a single object instance’s Destructor method to be called many times, if it happens to do something which keeps the object instance alive. This is rarely useful, but it might be useful if object instantiation is expensive and you want to keep a pool of instances ready for recycling, instead of allocating them fresh every time you need one.

Most classes don’t need destructors, so this is generally just an implementation detail. It might be useful if you had, for example, an object which represents a file handle, and you want to be sure that this system resource gets closed after the Xojo object representing it has been released.