FClassFinder triggers "libc++abi.dylib: __cxa_guard_acquire detected deadlock"

Development Programming & Scripting Blueprint
, , , , ,
1

Repro:
UE4 version: 4.10.2
OS: Mac OSX 10.11.3

  1. Create a C++ ThirdPerson template based project, with the generated ThirdPersonGameMode and ThirdPersonCharacter header and source files in the Xcode project
  2. Open up the ThirdPerson editor by running the Xcode project (Scheme: ThirdPerson → My Mac, I am using “DebugGame Editor” scheme with the extra “-debug” command argument)
  3. Inside the ThirdPerson Editor, create BP_ThirdPersonGameMode blueprint class, which derives from the native ThirdPersonGameMode class
  4. Inside the ThirdPerson Editor, make sure there exists the ThirdPersonCharacter blueprint class, which is automatically generated by the template, and I just happened to rename it to BP_ThirdPersonCharacter. Notice this BP class is derived from the native ThirdPersonCharacter class
  5. Open up the BP_ThirdPersonCharacter class in the editor, in its event graph, add a node “Get Game Mode”, and connect the output to “Cast to BP_ThirdPersonGameMode” - no other nodes needed, simple and straight forward, compile and save the BP
  6. Close the ThirdPerson Editor
  7. Back to the Xcode project, in ThirdPersonGameMode.cpp, add the following code:
  8. Relaunch the ThirdPerson Editor from Xcode, and observe the SIGABRT is triggered from within Xcode, and the output: libc++abi.dylib: __cxa_guard_acquire detected deadlock
  9. My speculation is that while default contructing AThirdPersonGameMode, the (static) class finder attempts to construct the same AThirdPersonGameMode object again, entering a recursive construction state, thus the lock guard is triggered (good!)
  10. However, being able to retrieve the class is crucial in that I needed to be able to spawn that blueprint character (or any other classes) from C++ code - think of an Actor factory being implemented on the C++ side.
  11. Is this a bug? or is there any best practice that I should follow to get around this?
AThirdPersonGameMode::AThirdPersonGameMode()
{
    //static ConstructorHelpers::FClassFinder<AThirdPersonGameMode> PlayerPawnBPClass(TEXT("/Game/ThirdPersonCPP/Blueprints/BP_ThirdPersonGameMode")); // this triggers the same signal
    static ConstructorHelpers::FClassFinder<AThirdPersonCharacter> PlayerPawnBPClass(TEXT("/Game/ThirdPersonCPP/Blueprints/BP_ThirdPersonCharacter")); // seems this blueprint class somehow becomes dependent on ThirdPersonGameMode because its blueprint event graph references GameMode!
}
2

So, to break out this recursive default object construction and the not so elegant class dependency introduced just by referencing another BP class in the event graph, causing the referenced class to construct a default object again (still a bug?), the workaround seems to create an extra BlueprintClassRegistry C++ Actor derived class, and put all the static class finder code inside the constructor of this BlueprintClassRegistry, and the actual gameplay C++ class (e.g. my C++ GameMode class) can thus reference the static results without introducing any further inter-dependency and recursive construction, thus no more deadlock!