Assert failed in UNetDriver::ServerReplicateActors()

Sometimes when I start multiplayer PIE session my Editor crashes with assertion failed inside UNetDriver::ServerReplicateActors().

This is line with assert:

check (World == Actor->GetWorld());

Here is explanation of what’s going on:

When Editor setups PIE session it spawns a bunch of actors, and some of them get added to NetworkActors array of each World.
One of those actors is AAbstractNavData.

Here is screenshot of debugger when it happens (File: World.cpp):

By time execution reaches NetworkDriver::ServerReplicateActors() this AAbstractNavData gets garbage collected, but pointer in array still exists (Notice pointer addresses of items with index [1] in both screenshots):

Then this actor pointer is removed from NetworkActors array because its NetDriverName not equals to this (Line 1953) and everything works fine after that.

But sometimes garbage collection starts a litlle bit earlier – just before second PIE world is created. When Editor spawns actors for it, memory allocator could give a chunk of memory previously occupied by AbstractNavData to a new Actor. Though this new Actor never get directly added to NetworkActors array of another World pointer to it is already there.

This was tested on 4.8.2 version downloaded with launcher.

Hi Druha,

Thanks for your report! I’ve assigned one of our team to look into this, and they’ll let you know if they have any questions.

Hi Druha,

Can please provide me with callstack and crash logs that you receive from this crash? It would be best to crash while running editor through usual way instead of Debug as CrashReporter isn’t triggered when running in Debug mode. On top of that, could you either upload code related to this spawning that is causing these crashes or a project where issue occurs? Any of these things will help determine if this is in fact a bug and if so, get it reported so that we can ultimately fix it.

I’ve tried to reproduce it in a new project - it crashed only once out of a hundred attempts, but i’ve collected some additional valuable data. Here is [crash dump & logs][2] from this [Test project][3].

To score a crash you need to start a multiplayer PIE session (I tested with 2 players). If it doesn’t - stop it and run again. It crashes very rare because when some other UObject takes memory of garbage collected AbstractNavData it does satisfy condition on line 1945 (GetRemoteRole() == Role_NONE) and get removed from array before check against World is performed.
In attached project it is almost always a UStaticMeshComponent that end up being in this list:

So in this case it is not even an AActor* that is stored in TArray of AActor*. In this situation anything may happen when pointer to one type of object is treated as pointer to other type.

Hello,

I have stumbled upon same issue reproducible on 4.8.2. This is reproducible 5 out of 5 times on my project. And another worrying side effect as a result of this crash is that in my blueprint game mode class default pawn class is automatically changed to DefaultPawn from None and it remains that way even after reopening and changing.

It’ll be great to get more information as to what is triggering this issue.

In my case this is how this error occurs :

If I set my DefaultPawnClass to None in Game mode class and override this game mode class in world settings and start a network PIE game session by selecting 2 players. As soon as 2 windows are shown it crashes immediately.

Interestingly If I set DefaultPawnClass to DefaultPawn or something else crash does not occur.

And in assert World pointer is being referenced from WorldSettings actor.

Please let me know if you need any more information from my end

Thanks :slight_smile:

I’m still looking into this crash and trying to reproduce it so that I can get it reported but I’ve had no success thus far. In meantime, can both of you try making a copy of your project to see if this issue persists in 4.9 Preview 1? It is possible that it has been inadvertently fixed.

Looks like 4.9 may have fixed issue. I was not able to reproduce it in my project. This commit may be solution, but I’m not sure. Is there any chance that 4.8 may include fix?

I doubt that it will be included in a hotfix. If this is commit that actually fixes issue you should be able to add it yourself to a 4.8 build, providing that you’re using a version of engine built from source code.

Gam3r, have you had same results? I’d be interested in knowing if 4.9 fixes issue for you as well since you had a 5 out of 5 reproduction case.

Hi, Just jumping into this thread in order to add more info.
we have integrated commit mentionned by Druha (here) alongside with this commit (here which fixes build), and I was still able to reproduce exact same crash described by Druha.

version we use is source from 4.8.3 + these two specific commits.

It’s a very rare crash (happening once or twice a day in a team of 10 people).

Hello la_taupe15,

Have you tried to see if crash occurs for you in 4.9 Preview? I’m interested to see if commit itself is incorrect one and fix is elsewhere.

Hi, no I haven’t tried to repro crash with source from a 4.9 preview. I’ll give it a shot and I get back to you as soon as I can :slight_smile:

Hello la_taupe15,

Have you had a chance to give 4.9 a try thus far? I don’t mean to rush you or anything of sort, I’m only curious.

Hi ,

We’ve just switched all our team members to 4.9.0 no repro of this crash has been reported yet ! :slight_smile:

Glad to hear it. Thank you testing this out!

We are experienced this crash after moving to 4.10, is this commit official fix?
strangest it only happens in one of our maps, and it crashes when asserting world settings.
Is there a way we can recreate world settings or validate map’s binary? Our map is already too big to be done from scratch

Hello issacvega,

Unfortunately we’re not sure if that was official fix as it was speculation since a bug was never entered for this issue. Could you post callstack and logs you’re getting when you crash? It could point toward specific problem.

If you would prefer it to be private, that would be best. Feel free to mention this post for context if you do.

Absolutely. A bit more details.
It only happens with Single process checked in with PIE.

We have a lot of logs of our own systems, I don’t think I should post that information here, should I move all info to a UDN thread?