This is more of a documentation issue than a bug.
If object instances are created in a function, then a GC cycle occurs. The references are destroyed which could lead to a crash. You'll see something like Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0xffffffffffffffff The pointer was freed and set to -1.
For example, a GC could be triggered by an editor tool calling UEditorAssetSubsystem's deleteAsset. All non-rooted instances created before the delete will be cleaned up.
There are three workarounds:
- Create your instances after the function which causes the GC.
- Root your instances. Call
addToRoot before the GC, and removeFromRoot when you're done so the reference can be GC'ed.
- Store the reference in a
uprop of another object instance, and nil it when you're finished.
If you're making a call from Nim to a function loaded from a Blueprints this can also be triggered. In that case, follow workaround 1 or store your references in something global.
This is more of a documentation issue than a bug.
If object instances are created in a function, then a GC cycle occurs. The references are destroyed which could lead to a crash. You'll see something like
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0xffffffffffffffffThe pointer was freed and set to -1.For example, a GC could be triggered by an editor tool calling
UEditorAssetSubsystem'sdeleteAsset. All non-rooted instances created before the delete will be cleaned up.There are three workarounds:
addToRootbefore the GC, andremoveFromRootwhen you're done so the reference can be GC'ed.upropof another object instance, and nil it when you're finished.If you're making a call from Nim to a function loaded from a Blueprints this can also be triggered. In that case, follow workaround 1 or store your references in something global.