Occasional UNet-related crashes on iOS

Unity Engine
,
1

Hi there,

We’re encountering occasional crashes in our iOS app and they seem to be related to UNet by looking at the stack trace.

The iOS app (game) maintains a connection with a dedicated server (both using UNet), and the connection might be alive for a few seconds when the app is backgrounded, but every once in a while, bringing the app back from background causes it to crash, spitting this stack trace:

http://crashes.to/s/c7cc1193f38

Also, we temporarily made the game disconnect from the server upon entering background, and reconnecting when the app is pulled back up. That didn’t seem to change anything.

We also have an Android release of this game, and none of our users encountered this issue, so it seems to be iOS-only. I tried to dig deeper through the stack trace and debugging in Xcode, and noticed this next log (printed after entering background) might be related to the issue:

2016-06-12 15:51:27.354 iTrix[1534:615761] Snapshotting a view that has not been rendered results in an empty snapshot. Ensure your view has been rendered at least once before snapshotting or snapshot after screen updates.

Currently, this issue is affecting every iOS user in our test pool. We’d love some guidance on this issue.

2

I am experiencing the exact same issue, and have not been able to solve it. Any help on how to solve this would really be appreciated.
We also connect from our iOS to a dedicated server. If the app moves to the background and then comes back causes occasional crashes. This Only happens after the connection screens not before so is definitely related to UNET.

3

I’m glad I’m not the only one having this issue. Mind if we exchange some information to help figure out the cause?

We’re not using many of the HLAPI classes like NetworkManager, NetworkBehaviours, SyncLists and others, so I can’t imagine they’re the culprit.

Our app mainly uses NetworkClient to establish the connection, and manually handling all events via NetworkClient.RegisterHandler (connects, disconnects, messages) and parse the data in a custom message handler.

Not sure if that helps, but I hope we can get a solution soon.

4

Unity patch 5.3.5p4 was just dropped, with the following fix:

  • (none) - Multiplayer: Cleaned up the connection containing StateUpdate channel can cause crash.

We’re also encountering crashes on the server (Windows headless server). Not sure if it’s UNet related, but I hope that fixes both (or at least one).

Not sure how to get the crash log. I enabled player log in hopes of catching the crash in there instead of staring at the vague Windows exception when it crashes.

5

2 questions:

  1. What unity version do you use?
  2. Is it new bug or old? Did you see them in previous version or you just didn’t try them?
  3. Are you able reproduce them easily
6

So far before you will put application to background turn please unet totally off by calling NetwrokTransport::Shutdown function, when you will put application back from background, Init unet again. So the algorithm sould looks like:

  1. disconnect client from all connected peers
  2. NetworkTransport.Shutdown
  3. Goto background
  4. Awake from background
  5. NetworkTransport.Init
  6. Initialize your internal code
  7. make connection again

Hope it should help

7

Sorry, I should have known to mention the version.

  1. We’ve built on 5.3.5f1 as well as 5.3.5p1. I’m about to test on the new patch (5.3.5p4).
  2. We haven’t tried other versions, this is our first release that uses UNet.
  3. Somewhat. I’m not able to reproduce it every time, but a few minutes of backgrounding/reopening the app (perhaps between packet sends/receives or even disconnects/reconnects) will definitely crash it.

I will try to figure out a less complex way to reproduce it and narrow down what I mentioned in (3).

8

I can try that. We’re hoping for a solution that can keep the connection alive as long as it can be while the app is backgrounded (on iOS, the native notification causes OnApplicationPaused to fire, bringing app to the background. Also the user might switch to a messaging app for a quick reply, or adjust the screen brightness.)

I realize we are not calling NetworkTransport.Init entirely within our client code (app)

This is how our connection is set up:

public static ConnectionConfig CreateConnectionConfig()
        {
            ConnectionConfig conConfig = new ConnectionConfig();

            conConfig.NetworkDropThreshold = 20;
            conConfig.DisconnectTimeout = 5000;

            conConfig.AddChannel(QosType.ReliableSequenced);

            return conConfig;
        }

private void SetupClient()
        {
            client = new NetworkClient();

            HostTopology topology = new HostTopology(CreateConnectionConfig(), 3000);
            client.Configure(topology);

            client.RegisterHandler(MsgType.Connect, OnConnect);
            client.RegisterHandler(MsgType.Disconnect, OnDisconnect);
            client.RegisterHandler(MsgType.Error, OnError);
        }

It works perfectly without the NetworkTransport.Init call, is it necessary?

9

HLAPI should do Init() call. So you need just shutdown call (and I.m not sure what you need to call to cleanup hlapi stuff, probably nothing. Shutdown itself will cleanup all network code from the core, stops network update threads and so on. So after this call you will need start everything from scratch.

We’re hoping for a solution that can keep the connection alive as long as it can be while the app is backgrounded
I’ve got this in my to do list. But cannot promise that it will be implemented fast.

10

@Sour Yup looks like i found problem in 5.3. Unfortunately it is possible will take more than one week before new patch. If you want ping me directly and I will deliver custom build for you with this possible fix (I mean possible because I haven’t chance to reproduce and test them, but im pretty sure that it will fix your problem)

11

We are using 5.3.4f1 and our project does use the HLAPI, stuff like Network Managers and SyncLists. Ill try the patch and Disconnecting Unet for now to see if it fixes the issue.

12

ok fix added and will be delivered with Patch 5, on June 22

13

Great! Thanks for your effort and prompt response.

Any idea if this other issue could be related at all? (one we’re having with our dedicated UNet server)

14

So I finally got my hands on the 5.3.5p5. It no longer seems to crash, but instead prints “recv udp socket error: {57}” repeatedly and indefinitely when debugging in Xcode (after backgrounding the app for 5-10 minutes while connected then coming back). Of course, this locks up connectivity on the app.

15

Update: I managed to get it to reconnect successfully after receiving many hundred “recv udp socket error: {57}” errors by cleaning up the NetworkClient instance using NetworkClient.Shutdown then replacing it with a new instance. This only happens if the backgrounded app has been backgrounded for over 5-10 minutes.