Correct C++ Storage

SDKs Plugins
1

Greetings all and Happy New Year.

Windows x86 Win7. Xojo 2017r2.1 (The last x86 IDE).

I’m having an issue with my custom plugin. I believe it may be be related to how I’m storing a global object reference in my module.

The symptom is that after I store the reference, any attempt to access the property again crashes the app with an access violation error from Windows.

MUST I use the C++ ‘static’ keyword on my stored reference to ensure that the value stays between plugin calls and not cleaned up by Windows or the Xojo memory manager? I want multiple plugin files to be able to access this property, so I recently changed it to the following:

[code]extern REALobject myDict = nil;

//getter & setter:

REALobject MyDictGetter(void) {
return myDict;
}

void MyDictSetter(REALobject dict) {
REALLockObject(dict);
REALUnlockObject(myDict);
myDict = dict;
}[/code]

If this is incorrect can someone (Christian or Bjorn) advise the correct code for this.

Many thanks once again.

  • Grant
2

Your getter misses the call to REALLockObject.

3

So within a module, you have to lock an object when saving AND when retrieving? Does the reference counter decrement when it’s accessed? This sounds like odd behaviour to me.

Do you have to do the same for REALstring?

Thanks Christian.

4

@Grant Singleton — You need to lock an object each time you create a new reference to it, which includes duplicating the reference as in your Getter function.

What happens is that when a method calls your Getter, it gets a reference to a Dictionary. When this reference is no longer needed, it automatically unlocks the Dictionary which may be destroyed, causing a crash later on. As a consequence, you need to call REALLockObject every time you return myDict.

So your Getter would be like:

REALobject MyDictGetter(void) { REALLockObject(myDict); return myDict; }

5

Christian & Stphane,

Thank you most sincerely to you both. Sorry for my delayed reply as one has just taken delivery of a new Mac Pro.

The call to REALLockObject has fixed the main crashing problem, but would still crash at random times, then I got thinking… in a module, nothing is done for you like zeroing storage space like Xojo does with classes and the classdata structure. All my variables were not initialised to nil, which means there may have been random data at that location. When a call to REALLockObject occurs, as per a previous post I’ve seen, Xojo guarantees the nil object checking in REALLockObject, which is fine, but when there’s uninitialised random data in my stored pointer variable, REALLockObject tried to used that data and whammy, an access violation occurs and a crash.

Initialising all my module variables to nil has solved the bulk of my crashes, however, there’s another which keeps on popping up randomly which is frustrating and annoying:

Universal\\REALstring.cpp: 130 Failure Condition: usageCount

What are the rules regarding the locking of strings with REALLockString?

Currently I’m locking all strings from my module and classes before returning them to the user. The plugin examples I’ve seen from Xojo don’t do that. Could this be why? Am I over locking strings?

Cheers & Happy New Year
-Grant

6

The usageCount failure is usually a missing REALLockString.

Lock strings you return unless you just built it.

7

[quote=469680:@Christian Schmitz]The usageCount failure is usually a missing REALLockString.

Lock strings you return unless you just built it.[/quote]

Does that apply to Xojo routines like ‘REALAddStrings’ as well, or is the returned string result already locked by Xojo?

Cheers
-Grant

8

REALAddStrings returns string with lock count 1.
You can pass that back to caller.

9

[quote=469685:@Christian Schmitz]REALAddStrings returns string with lock count 1.
You can pass that back to caller.[/quote]

Awesome! Thank you Christian.