Photon on iOS Crash when back from Background

kamend

Hi,
We found the following problem. While we are connected to Photon and we go into the background and after few seconds (PhotonNetwork.BackgroundTimeout is set to 5), if we open the app again, we get this error.

Any idea what might be the problem? The weird thing is that this is not happening every time.

Unhandled Exception: System.ArgumentException: get_gameObject can only be called from the main thread.
Constructors and field initializers will be executed from the loading thread when loading a scene.
Don't use this function in the constructor or field initializers, instead move initialization code to the Awake or Start function.
at NetworkingPeer.LocalCleanupAnythingInstantiated (Boolean destroyInstantiatedGameObjects) [0x00000] in :0
at NetworkingPeer.LeftRoomCleanup () [0x00000] in :0
at NetworkingPeer.OnStatusChanged (StatusCode statusCode) [0x00000] in :0
at ExitGames.Client.Photon.EnetPeer.Disconnect () [0x00000] in :0
at ExitGames.Client.Photon.PhotonPeer.Disconnect () [0x00000] in :0
at NetworkingPeer.Disconnect () [0x00000] in :0
at PhotonNetwork.Disconnect () [0x00000] in :0
at PhotonHandler.FallbackSendAckThread () [0x00000] in :0
at System.Func`1[TResult].Invoke () [0x00000] in :0
at ExitGames.Client.Photon.SupportClass+<>c__DisplayClass1.b__0 () [0x00000] in :0

(Filename: /Users/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 37)

Tobias

I think I know the cause for this but have to look into it, for a fix.
We have a fallback thread, which keeps the connection when Unity doesn't call Update(). If this thread disconnects, it triggers the clean up in this context, which fails.
It seems we have to wait until the engine runs it's next Update().

Tobias

Any update? Did you resolve the issue or can you send us a repro case?

kamend

I thought, that you are going to fix this? We are still getting the same crash on Android too.

Kest

we have same problem . we use pun 1.66,use TCP ,when back from Background after 20 seconds , game was crashed. use xcode debug, only info : singnal SIGPIPE.

can you help me?

Tobias

We changed the BackgroundTimeout to fix this. It no longer calls Disconnect() directly. Now it just stops the "fallback thread" from acknowledging messages from the server after a while, which can trigger a timeout after some more seconds.
This will be in PUN v1.67 but you can apply the change by updating 2 methods in PhotonHandler:

    public static bool FallbackSendAckThread()
    {
        if (sendThreadShouldRun && PhotonNetwork.networkingPeer != null)
        {
            // check if the client should disconnect after some seconds in background
            if (timerToStopConnectionInBackground != null && PhotonNetwork.BackgroundTimeout > 0.001f)
            {
                if (timerToStopConnectionInBackground.ElapsedMilliseconds > PhotonNetwork.BackgroundTimeout * 1000)
                {
                    return sendThreadShouldRun;
                }
            }

            PhotonNetwork.networkingPeer.SendAcksOnly();
        }

        return sendThreadShouldRun;
    }

    protected void OnApplicationPause(bool pause)
    {
        if (PhotonNetwork.BackgroundTimeout > 0.001f)
        {
            if (timerToStopConnectionInBackground == null)
            {
                timerToStopConnectionInBackground = new Stopwatch();
            }
            timerToStopConnectionInBackground.Reset();

            if (pause)
            {
                timerToStopConnectionInBackground.Start();
            }
            else
            {
                timerToStopConnectionInBackground.Stop();
            }
        }
    }

kamend

Than we have to manually track that we are actually disconnected, after we come back from background. May be mark that the fallback thread is stopped and call Disconnect after the client is back to foreground?

Tobias

A timeout-disconnect will happen when the app becomes active again. So you don't have to check manually but it will act like a timeout due to connection issues.
If that's inconvenient, I could possibly track the timeout reason as being inactive too long.