Could someone assist me in figuring out what is causing UE4.12.3 to crash when using a C++ class to spawn AActor objects?
Basically, I created an (Actor derived) C++[SpawnController] class that spawns 500 AActor objects and maintains them in a TArray.
In the ::Tick() method the positions of the AActors are updated (just for experimentation) using ->GetActorLocation() and ->SetActorLocation(). I am assuming that the way I iterate through the array and update positions is valid but if not let me know if there is a better/safer way to do it.
All is well for about a minute after running PIE, then suddenly the BP_Sphere spawned object count begins to drop rapidly.
I am not destroying the objects and they aren’t falling out of the world. Nonetheless, I think the 500 element array becomes corrupt which eventually crashes UE4.
I debugged as far as I could but the only thing of interest I found is that there doesn’t seem to be any crash if I disable physics and gravity on the spawned BP_Sphere object .
A crash report was submitted at the time of the crash as shown in the video.
Thanks.
Hey -
The actors appear to be getting cleaned up by garbage collection. This is causing the call to GetActorLocation() to fail since the specific element of the array no longer exists. Rather than using TSubclassOf MeshType, you should be able to use AActor* MeshType to avoid having the actors garbage collected and prevent the crash.
Cheers
Thanks .
AActor MeshType* didn’t work and caused compilation error:
*Error C2664 ‘T *UWorld::SpawnActor(UClass *,const FVector &,const FRotator &,const FActorSpawnParameters &)’: cannot convert argument 1 from 'AActor ’ to 'UClass
Instead I used UClass MeshType* and that appears to resolve the issue.
No crashes or disappearing objects after running for 5 minutes but I’ll keep an eye on it to be sure.
For my future reference, could you offer a brief explanation as to why a seemingly normal ‘live & visible’ spawned actor would later be flagged as garbage and removed so unceremoniously?
Cheers.
After adding a breakpoint and walking through the code, what appears to be happening is not a garbage collection issue. From what I can see, because the actors are not checking collision, they are falling through the “cracks” of the landscape and then out of the level. It’s calling CheckStillInWorld() and returning false from if(GetActorLocation().Z < WorldSettings->KillZ) just prior to calling AActor::Destory(). Adding a check to prevent the movement if it is overlapping would be one safe way to avoid the crash. A NULL check for the array element would also ensure that the actor still exists before attempting to update it’s location. If the NULL check fails, you can instead remove the element from the array so that it does not attempt to access an element that does not exist.
Thats strange because:
(a)
since using UClass* I haven’t experienced any crashes or disappearing objects
(b)
I previously positioned myself beneath the landscape crater to check if any objects were falling through but none were. The object count would go down regardless.
I added a null check just a precaution, but it would be better if no objects could disappear at all.
“From what I can see, because the actors are not checking collision, they are falling through the “cracks” of the landscape and then out of the level”
The spawned BP_Sphere objects have physics enabled and are set to [PhysicsActor] (they drop into and and collide with the bottom of the crater).
Is there some other collision setting you are referring to?
Here are two screenshots (seconds apart) of when the cascade of actors first reach the bottom of the crater and a couple seconds later. As you can see a large number have fallen through and continue to fall until they reach the “bottom” of the level (KillZ) and are destroyed. When destroyed the pointer becomes NULL (if it’s a smart pointer) or is then pointing at garbage memory. As mentioned, a NULL-check would prevent the pointer from being reference.
Aah, now I’m getting the fall throughs! - even with UClass*
(probably just coincidence that none fell through yesterday when I was testing it).
I decided to implement a NULL check and respawn if a dangling pointer is found. At least the array count will always stay consistent.
Thanks .
