Arrays with objects created with a plug-in will be never released from Xojo

SDKs Plugins
1

I have a simple class that have a constructor, a destructor and one property. If I use the following code in Xojo:
Dim a(-1) As MyClass
a.Append(new MyClass)
a.Remove(0)

The constructor of the class will be called once, and the destructor of the class will be called once. That’s what I’m expect.
If I implement a method, that will return a array with my class by myself:
REALarray tmpArr = REALCreateArray(kTypeObject, -1);
for (int i = 0; i < 2; i++) {
REALobject myClass = REALnewInstanceOfClass(&MyClassDefinition);
REALInsertArrayValueObject(tmpArr, i, myClass);
}
REALLockObject((REALobject)tmpArr);
return tmpArr;
Only the constructor will be called, never the destructor. I see in the Xojo Debugger the created array, which is correct. If I call a.Remove(0), the destructor will not be called too. So if I’m create arrays by myself, I will create memory leaks with objects.
What’s wrong with the code?

2

That is too much.

3

Hello Christian,
thank you for your fast response. I have removed the line with the lock command. But it will not change the behaviour. The objects in the array will never be released. Any other suggestions?

4

there is also a REALUnlockObject missing there for this.

5

Thank you Christian, the problem is solved. The documentation about the reference counting is very poor. I wasn’t aware, that REALInsertArrayValueObject will increment the reference counter. I expect that the REALSetArrayValueObject does the same?! I wish that a plug-In developer has the chance to access the current value of the object reference counter for testing propose. Or an event better SDK documentation to avoid such questions.

6

Yes, they will both add one to reference count.

7

Dereference the object pointer. It starts with 3 pointers and then the int with the reference count.

8

Perfect :+1:, Thank you!

9

Basic locking rules:

  1. You call method, do not lock.
  2. You return Object or string - Lock
  3. You call event, same as method, do not lock
  4. You get in object as parameter, lock only if you want to store it. (and then unlock when no longer needing).
    5.You get object in as property, lock if you want to store it (and then unlock when no longer needing).
  5. Property getter, lock when returning, same was rule 2.
1 Like
10

Thank you Björn. Since Christian told me to remove the REALLockObject((REALobject)tmpArr); command before I return the array, I have another question about your lock rules:
2.) Need a REALArray never to be locked if I return it? Or only, if I return a REALarry without to insert something?
4, 5) The same handling for REALarray?

11

REALCreateArray returns an array with a lock reference count of 1.
So you can just return it. Or put it in a C++ class variable.
But if you do both, add another reference by calling lock again.

1 Like