Fatal Error: ToString and ServerReplicateActors_BuildConsiderList

Hello again Unreal Forums!

This is a painful one. In the past my game has packaged and worked correctly many times. I started doing some replication/design modifications with animations (which may or may not be relevant) and I started experiencing this error when the client attempts to join a hosted lobby over the internet.

Specifically ONLY in the packaged build (using development build)

I’ve tried using WinDBG and attaching with Visual Studio debugger but because I don’t have engine symbols I’m unable to set a breakpoint on the ServerReplicateActors_BuildConsiderList function. Which is unfortunate because I could probably fix this.

Anyways, if anyone has experienced something similar it would be really great to have some insight. I’m having a lot of trouble with this one.

1 Like

I had errors with NetDriver when I had a slash or backshash in the variable/function/graph name.
For example, the On/OffLight RPC event caused a crash.

Also, running Actor Sequence on a replicated actor on client could lead to a crash, but everything started fine on the server.

Thanks for the response! I should have been more specific in my initial post, I’m a bit tired after many debugging hours.

The server is actually the one crashing. The client survives and gets sent back to the main menu.

Regarding your comment, I mostly use C++ and don’t have any variables or strings with either type of slash in the name. Also, the relevant blueprints don’t have them as far as I can tell but I’ll keep looking to triple check.

Could you be a bit more specific about “running Actor Sequence on a replicated actor on client”? Are you saying running an Animation Sequence on a replicated actor on the client side could cause a client to crash?

1 Like

Probably. You can try to disable replication in the supposed actor and check.
But even in my case with Actor Sequence this did not always lead to a crash.

Well I reset all of the animation settings back to default in the ABP and commented the Animation functions in my custom AnimInstance but with no luck. The search continues!

Update:

Still no luck. I resorted to building the engine from source to get debug symbols and I think it will ultimately help track this down but hasn’t so far! I’m now seeing this call stack:

I am also getting the UE_Log message: “was found in the NetworkObjectList, but is PendingKillPending”

Which is where the error is happening. The actor that the engine is trying to call GetName() on is null and therefore throwing the exception. The problem is this actor name looks like this:

neByteProperty￀IntPropertyᅪ4BoolPropertyvFloatPropertyᅪᄇObjectPropertyNameProperty,DelegatePropertyネDoublePropertynArrayPropertyᅪᄁStructPropertyヨVectorPropertyᅫRotatorPropertyᅪ¬StrPropertyᅪ TextPropertyNInterfacePropertyᅪ@MulticastDelegatePropertyᅪᄚLazyObjectPropertyトSoftObjectPropertylInt64PropertyᅪVInt32PropertyᅪHInt16Propertyᅪ*Int8PropertyネUInt64PropertyᄄUInt32Property
ᅠUInt16Property￈MapPropertyᅪᅵSetPropertyᅪ&_0

Obviously that’s not much help. Oh well, we keep going.

Major headache. Bumping this in case anyone has any ideas of how I could identify what actors are being passed into the BuildConsiderList function. I can see a nullptr being passed in and then it’s crashing. But I’m just not sure how to identify what actor that is.

To be fair, I don’t get to spend much time on this during the week :frowning: so WHEN I figure it out I will let you guys know! But, a nudge would be so nice!

1 Like

I remember one time my project froze when turning the camera in a certain direction on a certain level. I couldn’t think of anything smarter than to remove 50% of the actors from the level to find out which of them was causing the freeze. Then another 50%, and another… And so I found out that the problem was in the volumetric fog in the background, which in general does not affect the picture in any way.

And the funniest thing is that it was a default actor from a template level, but at one point he started to ruin everything. :grimacing:

I think you can do it in about 30 minutes.

Hey dude, thanks for the response again! You’re absolutely right and I probably should have already tried this technique. I’ve commented a lot of code and tried to see if any of those systems were the problem but with no luck. This seems like a good logical next step.

Up to this point I’ve felt like it was a replicated variable or something thag was likely causing it but I guess I dont see why that would cause a whole actor to be null. Whats weird to me is this game has worked as a packaged build many many times before. I did some modifications to the MatchState enums, HUD, and animations. I’m like 99% sure one of those things is causing it but even after commenting code, recompiling, repackaging I cant seem to find it.

I will test your solution later today and we’ll see!

I also remembered one nuance, when I spawned a replicated actor on the server, and then immediately transferred a reference to it to clients via Multicast RPC.

When RPC was marked as Reliable - the reference at the time of the call was not valid on clients. Sometimes (I did not understand why exactly) after some time the reference from the RPC event could become valid, even without a repeated call, but sometimes it remained broken. But at the same time the actor appeared on clients.

Reliable forces NetDriver to first send an event, and only after that a command to spawn the actor on clients (Begin Play of the actor on clients was triggered after the event of reference transfer).

When I removed Reliable - the reference became valid at the time of the call.

So I’ve tried a few things…

I’ve basically taken out all of the code related to animations and HUD updates (which I thought might be it) but that didn’t solve it.

I also attempted your solution and removed all of the actors in the level. The only actor left was the actor (character/pawn) that was spawned in at the start. So I have to assume it’s something with the character that’s causing it. But I’m really not sure what that could be unless a component or something is doing it.

It’s worth mentioning this is all in the packaged build when attempting to test the game over Steam (which has worked just fine in many packaged builds before this).

First the game sends the server host to a lobby, then the client finds that session successfully and joins it then (it appears) the transition from the lobby to the map the game will be played on is where it’s failing. If I step through the code I can see the other character appear on the lobby screen briefly while debugging. The client screen is already in the new map but the server then attempts to transition back to the main menu map and into the new one (I guess?) and that’s where it fails.

It’s hard for me to say because I’ve never stepped through it specifically and these were just things Unreal handled in the past. The MatchState changes from EnteringMap to WaitingToStart and then the crash happens. At this point (I believe from debugging) that it’s after the very first tick of the GameMode that it’s failing.

I know it’s some actor being a nullptr, which it may be the client version of the character, I don’t know, but I can see at least one of the characters being passed successfully in the ServerReplicateActors_BuildConsiderList function during debugging.

I just noticed this in the log too:

[2024.10.17-21.37.39:284][657]LogGameMode: >> GameMode::HandleSeamlessTravelPlayer: GymPlayerController_2147482328 
[2024.10.17-21.37.39:285][657]LogGameMode: << GameMode::HandleSeamlessTravelPlayer: BP_GymPlayerController_C_2147482209

So it does appear the game recognized both of the PlayerControllers and travels them to the new map. I wish I knew the engine deep enough to say more than just the random things I’ve been looking at. At this point I guess the next step is to disable replication for things on the character one by one until maybe it goes away? I’ve basically torn the game apart trying to identify what the hell is causing this.

Honestly, I’m sure it’s something really stupid.

Cheers

Edit: Adding in this picture of the null actor too in case that holds clues I’m not seeing. It has an inputcomponent so I’m assuming it’s a PlayerController/Pawn/Character? Not really sure… Need to do more digging. I wish I could find the right debug point to just know when the heck this thing turns null!

OMG… For heaven’s sake, turn off the seamless travel in game mode. :skull_and_crossbones:

This thing sometimes does completely incomprehensible things, ESPECIALLY in multiplayer. And now I am 99% sure that this is exactly the case.

I havent been home and able to test but I will try this ASAP. Your response tracks though, I noticed some very strange things when testing a few days ago! I’ll let you know!

It turns out this was the issue. Which is insanely frustrating because I spent a long time trying to solve this lol. I still might try and solve it with this just because it makes literally 0 sense that this game worked for like an actual year and then all of a sudden it stops working and it’s not even related to a change I made? (I mean I guess it probably is some obscure thing but you know).

It’s worth mentioning that I’m pretty sure the issue was with the Spectator Pawns that were (maybe) being spawned after the character was deleted and trying to travel to the new map? During debugging it would go from SpectatorPawn1 straight into the invalid name.

Also worth mentioning that the core of this issue wasn’t actually a nullptr but it was a TSharedPtr that had an Invalid pointer inside of it (I guess a nullptr?). Which maybe invalidates what I just said about SpectatorPawns but it’s hard to say with just memory addresses. I’m not sure if I will try and debug this further or not but if I do I’ll post here. Thanks for your help PREDALIEN!

As far as I know, seamless travel only works (in cases where it works) if the game mode settings are the same on both levels (all classes that need to be saved must be the same). If this is not the case, and objects of a different class are created on the new level, then this is probably the problem.
But I did not delve into this that deeply. Disabling seamless travel completely in my projects suits me for now.