[Bug] Game Singleton and UObject
I have a use case that generates a crash in editor, and makes the development a living hell. This was working fine in 4.10 and after upgrade to 4.12, singleton related issues started to appear.
Currently, I'm keeping a few objects in a singleton class for easy access for the data I want to keep in memory for the entire game life. This includes a custom created TCP socket, and data containing TArrays and C arrays... nothing fancy.
The problem occures when the validity of the objects are checked. In editor, on game start, a custom "blueprint function library" static func creates the required items, initializes, etc. If these already init (or is valid) function does nothing, and uses available items. If you stop the game in editor, and restart again a bunch of different errors start to appear. One is about an IsValid call (main thread does not even make a call to my classes, just crashes). Sometimes it's about UObject not valid or TArray index is out of bounds... etc...
I found out that, the created singleton lives as long as the editor is on. However this have been different in previous versions. Singleton was destroyed when in-editor game test was ended.
Now, even though the singleton is not destroyed, it seems that it is not valid or the memory address is not readable (already released maybe?) and editor crashes.
I've created a sample project and wrote a few C++ classes to demonstrate what is going on. I can re-create the conditions on different windows machines so I believe this is a UE editor bug. The calls are directly in the level blueprint. It doesn't matter if you move it to another actor/pawn/etc blueprint, same problem occurs. You can download the project for testing from:
And here is the thread crash log from the crash reporter: CRASH LOG
So, UE is garbage collecting all c++ uobjects, even if the object's pointer is set in the game singleton object. Singleton is not destroyed, but everyting that is referenced from it is. So crashes on IsValid...
However, if I make the singleton blueprintable, and create a bp, set this as the singleton class of game, the references no longer get destroyed...
Yet, still, the singleton continues to exist even though the test has ended in editor. So, my TCP socket object is not destroyed, and connection remains open.
Not what I had in mind. Currently it works.
I also do not know if the singleton must be destroyed or not when editor test ends. In some cases, it is not desirable to let the objects live in memory, but in some, it might help you test multiple levels while data lives on... so exhausting to choose :)
answered Jun 24 '16 at 02:21 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here