EXC_BAD_ACCESS in simple application

[wtfork]

I've got a pretty simple setup since I've been stripping functions off of my initial build in trying to find the source of this issue.

Basically there are two classes- DesktopServer and RemoteClient (code below). The initial Scene has a TNManager object and a non-networked object that checks Application.Platform. If the runtime platform is the desktop (or editor) it instantiates a DesktopServer; if it's an iPhone it instantiates a RemoteClient. In either case, it calls

1. TNManager.StartUDP(Random.Range(10000, 50000));

before the instantiation occurs. The RemoteClient tries to connect to the first server it finds, which will always be the app running on the desktop.

85% of the time this works. But 15% of the time, I get an EXC_BAD_ACCESS error and the iPhone app terminally crashes (attached) which from the Unity Answers forum I think is likely to be a null reference exception (or I would if there were any external references going on here).

Here are my classes:

1. using UnityEngine;
2. using System.Collections;
3. using TNet;
4.  
5. [RequireComponent(typeof(TNObject))]
6. [RequireComponent(typeof(TNUdpLobbyClient))]
7. public class DesktopServer : MonoBehaviour {
8.        
9.         public int serverTcpPort = 5127;
10.  
11.         // Use this for initialization
12.         void Start ()
13.         {
14.                 int udpPort = Random.Range(10000, 40000);
15.                 TNUdpLobbyClient lan = GetComponent<TNUdpLobbyClient>();
16.                 int lobbyPort = (lan != null) ? lan.remotePort : 0;
17.                 TNServerInstance.Start(serverTcpPort, udpPort, "server.dat", lobbyPort);
18.                 StartCoroutine(Connect());
19.         }
20.        
21.         IEnumerator Connect()
22.         {
23.                 while(TNLobbyClient.knownServers.list.size == 0)
24.                 {
25.                         yield return 0;
26.                 }
27.                 TNet.ServerList.Entry ent = TNLobbyClient.knownServers.list[0];
28.                 TNManager.Connect(ent.externalAddress,ent.internalAddress);
29.                 while(!TNManager.isConnected)
30.                 {
31.                         yield return 0;
32.                 }
33.                 TNManager.JoinChannel(100,null);
34.         }
35.        
36.         void OnNetworkPlayerJoin (Player player)
37.         {
38.                 Debug.Log("Player Joined");
39.         }
40. }
41.  

and

1. using UnityEngine;
2. using System.Collections;
3. using TNet;
4.  
5. [RequireComponent(typeof(TNObject))]
6. [RequireComponent(typeof(TNUdpLobbyClient))]
7. public class RemoteClient : MonoBehaviour {
8.        
9.         // Use this for initialization
10.         void Start ()
11.         {
12.                 TNManager.StartUDP(10000);
13.                 StartCoroutine(Connect());
14.         }
15.        
16.         IEnumerator Connect()
17.         {
18.                 while(TNLobbyClient.knownServers.list.size == 0)
19.                 {
20.                         yield return 0;
21.                 }
22.                
23.                 TNet.ServerList.Entry ent = TNLobbyClient.knownServers.list[0];
24.  
25.                 //<<this is where the BAD_ACCESS occurs, based on Debug.Log calls>>
26.                 TNManager.Connect(ent.externalAddress,ent.internalAddress);
27.                 while(!TNManager.isConnected)
28.                 {
29.                         yield return 0;
30.                 }
31.  
32.                 TNManager.JoinChannel(100,null);
33.         }
34. }
35.  

Am I missing something obvious? As far as I can tell I've mimicked all of the core sequencing from the demo's connecting structure, which itself appears to run flawlessly. I've tried deleting the TNet folder from the project and reinstalling it through the asset store just to make sure I'm running vanilla...

[ArenMook]

Why do you start UDP at all? If you want server discovery then start a Lobby Client.

[wtfork]

Removing that... seems to work (it's hard to tell for sure since "verifying" the fix involves reloading the program a few dozen times to see if it crashes). Is there any particular reason why starting UDP like that would cause a crash later? I'm curious more than anything.

[ArenMook]

I have no idea. Make sure you don't have stripping on.

[wtfork]

I suspect it was a race condition between some background network processes, given the fix was and the stochastic nature of the error. Shrug? Gone now.