Articy objects being GCed - causes crash

[dread]

Hi,

There are a few issues here. First when ArticyDatabase object is cloned form the original asset it is held as a static weak pointer. This causes the object to be GCed after a while and forces it to be recreated from asset (which may take a significant amount of time because the asset is also GCed). The same happens with ArticyGlobalVariables object - this can reset the state of the game. The solution for this is to put the objects into UPROPERTYied class member variable or cache in a blueprint variable or call AddToRoot() on cloned objects.

But this doesn't produce the crash. Unfortunately similar case relates to all articy objects. Cloned articy objects are held in two maps: LoadedObjectsById and LoadedObjectsByName. Both of these maps are not UPROPERTY variables so they will get GCed. When this happens the first call to PlayBranch will crash in

Code: Select all

ArticyDatabase::GetOrClone<T>()

method due to casting the destroyed object (it crashes in

Code: Select all

bool UObjectBaseUtility::IsA<T>() const

).

To fix this I've added a UPROPERTYied

Code: Select all

TArray<UArticyPrimitive *>

variable which holds the clones of articy objects and prevents them from being GCed. The array is filled in

Code: Select all

UArticyDatabase::LoadPackage()

function using the primitiveClone variable inside the for loop. This doesn't allow the GC to destroy the cloned objects.

I'm not sure if this is a good solution. What do you think?

[dread]

There's also a problem with articy variables. The functions which access the variables using the reflection system incorrectly cast returned values which causes memory corruption and eventually crashes. I've put a pull request with fixes.

[[Articy] Peter Sabath]

Hi dread,

thanks for the feedback / report.

I have forwarded your message to the plugin dev to take a closer look.
A quick check of your suggested changes seem to make perfectly sense (Especially the fixes for the variables). But since I am not the dev here someone closer to the code should check for unwanted side effects.