UStaticMeshComponent->SetCollisionEnabled Access Violation (nullptr)

Development World Creation
, , , , , ,
1

Update
The problem is the IsTemplate() function called from OnComponentCollisionSettingsChanged() in the static mesh component. Within IsTemplate, it checks the flags of the Outer object, however, the outer object is null. I’ve confirmed this is due to garbage collection by setting the garbage collection time to 1 second.

I have a Pawn with a UStaticMeshComponent and when the player presses a button, the collision and visibility states of this mesh are toggled. However, after 60 seconds the engine crashes on SetCollisionEnabled with an access violation (null pointer somewhere). The component is a UPROPERTY and the component pointer is valid since SetVisiblity works just fine and is called immediately before SetCollisionEnabled. I can also do MeshComponent->GetBodyInstance()->SetCollisionEnabled without a problem, so it must be something during the physics state checks.
60 seconds is when the garbage collector kicks in, so something is getting garbage collected when it shouldn’t be.

Am I missing something or is this a bug? Thanks!

Relevant code (using generic names):
State is a boolean indicating the toggle state.

UPROPERTY(VisibleAnywhere, BlueprintReadWrite, Category = "Mesh")
UStaticMeshComponent* MeshComponent;

MeshComponent->SetVisibility(State);
MeshComponent->SetCollisionEnabled(State? ECollisionEnabled::PhysicsOnly : ECollisionEnabled::NoCollision); // Works fine until 60 seconds have passed then it'll crash

I should also add that using SetCollisionEnabled on this particular mesh component causes this warning and I can’t find any information on why:

FBodyInstance::ApplyMaterialToShape_AssumesLocked : PComplexMats is empty - falling back on simple physical material.
2

Turned out this was one of those problems that are caused by something else entirely and through debugging it, you discover and fix the root problem.
The problem seemed to be the way I was creating my components in the Pawn’s constructor. I was calling RegisterComponent and AttachTo, and it seems that removing RegisterComponent fixed the issue, which actually turned out to be my root component being garbage collected or not being registered properly or something along those lines.

3

short version:
I was using a BP made from a C++ class. Calling SetVisibility(...) on subcomponents crashed just like the above. Removing the BP of my class, and using only casts to the real class not BP in my other BPs fixed these sorts of problems.

long version:
In case it helps someone, a related problem I had was with a C++ actor class that would randomly crash and had strange behavior. I was creating a root component and 2 subcomponents, and the editor would randomly show more components with different names, and the visual representation it showed in the editor looked like something cached from long ago, and would still show that way even after cleaning out my project (deleting the dir and pulling from git and regenerating files).

In the C++ class, I can toggle visibility of subcomponents, and doing that crashed just like the above. Adding more fields, or changing the order of the fields in the .h file would seem to change the behavior.

But deleting any BP_MyClass in my levels/maps (but not actually deleting BP_MyClass itself) and directly using MyClass in levels/maps fixed the Access violations, other random crashes, huge performance lag when spawning actors, and some other oddities. And also removing casts to BP_MyClass in my blueprints fixed other problems and things I found weird (like it was calling the constructor 4 times, but now only 2 times for one object (but BeginPlay only once)).

And I was never using RegisterComponent or AttachTo, only CreateDefaultSubobject, SetRootComponent and SetupAttachment.