ObjectDisposedException is thrown when disconnecting as a host, when at least 1 client is connected.

[Gitspathe]

Description

When disconnecting while running as a host, with at least one connected client, an ObjectDisposedException is thrown, causing further network functionality to not work as intended.

Reproduce Steps

1. Run as a host inside the Unity editor.
2. Run as a client inside a build.
3. Connect to the host as a client.
4. Disconnect/shutdown as the host.

Actual Outcome

An ObjectDisposedException is thrown, causing further network functionality to not work as intended. The exception is as follows:

ObjectDisposedException: The Unity.Collections.NativeList1[Unity.Networking.Transport.ConnectionDataMap1+ConnectionSlot[Unity.Networking.Transport.ConnectionList+ConnectionData]] has been deallocated, it is not allowed to access it Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle.CheckReadAndThrowNoEarlyOut (Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle handle) (at <f9983213a0c04feda5c20751005e16ae>:0) Unity.Networking.Transport.ConnectionDataMap1[T].get_Item (Unity.Networking.Transport.ConnectionId connection) (at ./Library/PackageCache/[email protected]/Runtime/ConnectionDataMap.cs:42)
Unity.Networking.Transport.ConnectionList.GetConnectionState (Unity.Networking.Transport.ConnectionId connectionId) (at ./Library/PackageCache/[email protected]/Runtime/ConnectionList.cs:57)
Unity.Networking.Transport.NetworkDriver.GetConnectionState (Unity.Networking.Transport.NetworkConnection connection) (at ./Library/PackageCache/[email protected]/Runtime/NetworkDriver.cs:1112)
Unity.Netcode.Transports.UTP.UnityTransport.DisconnectRemoteClient (System.UInt64 clientId) (at ./Library/PackageCache/[email protected]/Runtime/Transports/UTP/UnityTransport.cs:1179)
Unity.Netcode.NetworkConnectionManager.OnClientDisconnectFromServer (System.UInt64 clientId) (at ./Library/PackageCache/[email protected]/Runtime/Connection/NetworkConnectionManager.cs:1026)
Unity.Netcode.NetworkConnectionManager.DisconnectRemoteClient (System.UInt64 clientId) (at ./Library/PackageCache/[email protected]/Runtime/Connection/NetworkConnectionManager.cs:1055)
Unity.Netcode.NetworkConnectionManager.DisconnectClient (System.UInt64 clientId, System.String reason) (at ./Library/PackageCache/[email protected]/Runtime/Connection/NetworkConnectionManager.cs:1085)
Unity.Netcode.NetworkManager.ProcessServerShutdown () (at ./Library/PackageCache/[email protected]/Runtime/Core/NetworkManager.cs:139)
Unity.Netcode.NetworkManager.NetworkUpdate (Unity.Netcode.NetworkUpdateStage updateStage) (at ./Library/PackageCache/[email protected]/Runtime/Core/NetworkManager.cs:89)
Unity.Netcode.NetworkUpdateLoop.RunNetworkUpdateStage (Unity.Netcode.NetworkUpdateStage updateStage) (at ./Library/PackageCache/[email protected]/Runtime/Core/NetworkUpdateLoop.cs:192)
Unity.Netcode.NetworkUpdateLoop+NetworkPostLateUpdate+<>c.b__0_0 () (at ./Library/PackageCache/[email protected]/Runtime/Core/NetworkUpdateLoop.cs:287)`

Expected Outcome

The host is disconnected without an error, and network functionality (such as propagating disconnection messages to clients) continues to function as intended.

Environment

• OS: OpenSUSE
• Unity Version: 2022.3.47f1
• Netcode Version: 1.11.0
• Unity Transport Version: 2.3.0

[NoelStephensUnity]

Hi @Gitspathe ,
I am not able to replicate the issue you are describing.
Attached is a replication project implementing the steps you have outlined and I am not seeing the error message.

3118_Replication.zip

Could you take a look at this project and compare it with yours to see if there is something else you are doing that could be the cause?

[Gitspathe]

I was able to replicate my problem. It appears if you first call Shutdown on UnityTransport before shutting down the server, then the issue occurs.

This happens in my project since I use multiple transports inter-changeably, so I had a manager set up which would first clean up transports before shutdown. I am able to work around this, but I would assume this isn't intended behaviour?

3118_replication2.zip

[NoelStephensUnity]

@Gitspathe
Well, the intended behavior is for the NetworkManager to handle shutting down the transport since there is an order of operations that needs to occur.
Let me look at your adjustments real quick...

[NoelStephensUnity]

@Gitspathe
Ok, so it was what I was thinking. When you shutdown the transport prior to shutting down the NetworkManager like this:

            GetComponent<UnityTransport>().Shutdown();
            Shutdown();

There are going to be several things that won't happen:

• Pending messages won't get flushed
• Sending a disconnect message to the host/server (or vice versa) won't occur
  • The host/server actually runs through a process to provide controlled disconnections prior to completely shutting down.
• There could be other NGO systems that might attempt to access the transport during shutdown.

Is there a specific technical reason why you are shutting down the transport prior to the NetworkManager?

[Gitspathe]

I handle the transport separately from the NetworkManager, in certain edge cases, because the Facepunch (Steam) transport requires you to start it for the Steam API to function. So typically I begin the game with Steam transport spawned, then I swap to Unity's UTP transport when playing single-player or without steam (shutdown facepunch -> start Unity UTP). Although I can work around this quite easily and it's more an issue with that 3rd party transport specifically.

Although the order of operations makes a lot of sense in hindsight, would it be possible to add a better error message for when my situation occurs? This was just hard to debug since with only 1 player, everything appears to work fine, but then with 2+ you get strange error logs.

I'd imagine the NetworkManager could just check if the Transport is shutdown or destroyed, and then give a warning/error based on that when you call Shutdown().

[NoelStephensUnity]

@Gitspathe
I think we can handle it more gracefully for sure, and was just wanting to better understand the use case scenario where this issue arises. Very appreciative of your bug submission and the time you have taken to provide additional insights into this issue. 👍