Exactly what Sam said. You typically won’t see a crash because
this is null, you would see the crash happen when calling a method on a class pointer that is null (or the instance was destroyed and the pointer now points to garbage). Since you are already in
this instance of UMainMenu is still valid, otherwise the game would have crashed on your call to SetServerList (probably
The actual line that is reporting the crash is misleading - probably because you are running in DevelopmentEditor, which I believe is the UE4 equivalent of running in ‘Release’ mode. This means that you aren’t going to get accurate debug info because of compiler optimizations. However, running the project in debug reveals the real culprit:
The problem is that
nullptr, and you are hitting the ensure macro. Instead of using the macro, you can simply do
if (!World) return; and the method will exit cleanly (I tested this myself and no crash).
As to why
World is null here? Well, my assumption is because we’re doing a
ServerTravel when we host a game. I think this might actually de-register the UMainMenu instance with the current world or a new World is created after the ServerTravel call returns and our UMainMenu instance hasn’t registered itself yet. I’m going to do some further debugging on this and will update this post if I can pinpoint the exact reason.
After running the debugger a couple times, it looks like AActor::GetWorld() might be getting called - note the comment:
UWorld* AActor::GetWorld() const
// CDO objects do not belong to a world
// If the actors outer is destroyed or unreachable we are shutting down and the world should be nullptr
if (!HasAnyFlags(RF_ClassDefaultObject) && !GetOuter()->HasAnyFlags(RF_BeginDestroyed) && !GetOuter()->IsUnreachable())
if (ULevel* Level = GetLevel())
So this makes sense as to why World could be nullptr. What doesn’t make sense is why AActor’s
GetWorld() is being called because our UMainMenu is actually a UUserWidget which also implements GetWorld(). It’s hard to say exactly what’s happening here but as I mentioned I did have to run the debugger several times before I was even able to step into the
GetWorld() function. Usually random behavior indicates some sort of race condition, perhaps UMainMenu is in an undefined state when
SetServerList() is called because we’ve transitioned to new map.
Granted, I had to click Join, then quickly go back to the main menu and click Host (and Host again from the set server name menu) to get into a map before the server list returned. This is probably not the typical use-case, and there are likely other ways we could break the game by performing an unintentional sequence of actions. I highly doubt Sam had an entire team of QA performing exhaustive stability tests on these demo apps. That being said, one thing we could do to improve the game’s stability is disable the Host button while a search is pending.