Crash when stopping play in editor

[Sarr]

Hi there,

I seem to have a little problem with a crash when stopping a play in editor,
in visual studio the crash appears as Critical Error PlayerState /Game/Maps/UEDPIE_0_Yira.Yira:PersistentLevel.PlayerState_35 Object from PIE level still referenced. Shortest path from root: (Object is not currently rooted)

from what I understand it is to do with my skill system , which (when the world is being destructed) has a pointer that points to an actor that holds all the available skills for the particular player character, and this pointer gets invalidated as the actor gets destroyed before the player character. what can I do about this?

Thanks.

[Naram-boiii]

I had a very similar problem, if not the same, and I soved it by storing the pointer to the destroyed actor in a TWeakobjectPtr, which if I understood it correctly, is emptied automatically, when the actor is destroyed (Please, do correct me ).

[Sarr]

Just wanted to update, I did not get the error while running the game standalone, also TWeakObjectPtr seems to have fixed my issue as well. Thanks !

[Naram-boiii]

You're welcome

[WCode]

Can i ask, when is it apropriate to use a TWeakobjectPtr / TSharedRef ?

[cmartel]

TWeakobjectPtr / TSharedRef ?

Vastly different things.

Remember that UObject pointers tagged as UProperties are reference counted so that whenever a UObject is no longer used anywhere, that object gets deleted by garbage collection. This means that if you have two UObjects referring to each other, they will always be using one another and therefore never get garbage collected. For instance, a controller might own a UI widget, but the widget needs access to the controller to poll certain values. In order to avoid these objects keeping each other alive, whichever widget is the "child" or dependent should refer to its parent through a weak pointer instead. Unlike regular pointers, weak pointers do not affect the reference counting, so that the controller can be deleted normally if everything else stops referring to it.

As the name says, TWeakObjectPtr is for objects, in this case specifically UObjects. There are many parts of the code where you might use native classes that don't need to be UObjects. But if you just allocate such an object using "new FMyNonUObject()", then you don't get reference counting and the memory management advantages it brings. The engine therefore provides special pointer templates that do just this with non-UObjects. They are basically the UE4 version of std::shared_ptr. These pointer templates keep count of what is referring to the object and automatically delete the object so that memory is not leaked.

These templates are TSharedPtr and TSharedRef. The two are very similar, except that TSharedRef is treated like regular C++ references and can never be null or changed. You extract a TSharedRef by calling .ToSharedRef() on a valid TSharedPtr. If you try to do that on a null TSharedPtr, the engine will yell at you to enforce the validity of shared references. This can be very handy in certain parts of the code where you know for sure than an object will always exist and you don't want to waste time null checking it.

Lastly, since all TSharedPtr and TSharedRef keep track of their references, you could end up with the same problem as with UObjects if you have two objects referring to each other. So the native non-refcounted equivalent of TWeakObjectPtr is TWeakPtr, which you build from a shared ref or shared ptr.

You cannot use UObjects with TSharedPtr/TSharedRef/TWeakPtr because they use a very different reference counting method. You can create a TSharedPtr by using MakeShareable, or making your class derive the TSharedFromThis template. Look throughout the engine code for examples of both.

-Camille

[WCode]

Awsome what a great answer cmartel ☆
Cheers!

[Sarr]

Well I seem to have the same crash problem I described in the first post, but with different objects now, and in this case TWeakObjectPtr causes crash before exit if I use it. and I'm unable to track down why as the crash points to one of the Engine dll files, this time, the Individual spell templates referenced by the spell database actor cause the problem, yet if i use Array<TWeakObjectPtr<ASkill>> Abilities, to store each of the ability templates, it causes crash when i try to access Abilities[x] to cast spell based on that template. I did check that the pointer does point to an existing spell while stepping trough my code, but as soon as I access the Abilities array, the engine crashes with " Access violation reading location 0xFFFFFFFFFFFFFFFF"
the Abilities array is
"UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Abilities)
TArray<TWeakObjectPtr<ASkill>> Abilities;"
I cannot figure out why this happens, any help would be appriciated

[Sarr]

Turns out for some odd reason.. the play in editor seems to hold all the data the player had when i exited the game... thus it holds the abilities from previous gameplays which are now null which is what causes a crash.... not sure why but emptying ability array on event game begin completely resolves this issue. Any insight why? I am using unreal engine 4.7 preview 2

I believe this may have something to do with the way I spawn the character component which handles abilities and such
Character_System = NewObject<UCharacterSystem>(UCharacterSystem::StaticClass());
Is this a correct way to create a new instance of a class? I do this in the constructor for my AGameCharacter