Editor crashes but Web Player works fine: what's the difference?

Unity Engine
1

I have a problem with a Unity Editor crash, when the code appears to work fine in a Web Player build.

(note: this is using Unity 3.5.5f3)

The situation is as follows:

  1. Our Unity client detects that it has lost its connection to our game server.

  2. It then displays a pop-up informing the user of the lost connection.

  3. The pop-up has a button the user can press to return them to the server list scene.

  4. The OnGUI method for the pop-up also has a timer which returns them to the server list scene automatically after a number of seconds have elapsed.

In the Web Player, the scene switch works just fine.

In the Editor, it’s fine if you press the button, but if you let it time out, the Editor crashes.

The code within the OnGUI call looks something like this…

class DisconnectForm : MonoBehaviour
{
	void OnGUI()
	{
		bool bReturnToServerSelect = false;
		if (GUI.Button(...))
		{
			bReturnToServerSelect = true;
		}
		if (checkForTimeOut())
		{
			bReturnToServerSelect = true;
		}
		if (bReturnToServerSelect)
		{
			Close(); // the Close function starts a coroutine "OnCloseRequested" which does the scene switching
		}
	}
}

I am struggling to debug this. One thing I have tried is adding a Debug.LogWarning
call in OnCloseRequested() to get the call stacks, and I’m wondering if the difference
is significant, in that the OnGUI() call is preceded by some stuff that looks specific
to the Editor.

Call stack on button press

Call stack on time-out (note first part is identical to the above, but it is preceded
by UnityEditor.EditorGUIUtility:INTERNAL_CALL_RenderGameViewCameras etc.

Can anyone explain this difference? I would have expected the call stacks to be the same.

Does anyone have any observations on how the Editor works (compared to the Web Player) that might help?

Or obviously any other ideas for things I could look into…

For what it’s worth, the call stack shown in Editor.log on crashing is…

2

Is your coroutine’s script enabled the entire time? And I assume you’re not running the coroutine every frame.

3

Not really solving your problem, but the editor and web player use completely different Mono versions, so some changes is not surprising to me.

4

Thanks for the replies. The different Mono versions fact is something I wasn’t aware of and I guess it could explain the difference between behaviours in the WebPlayer and Editor.

I seem to have fixed it now through a bit of trial-and-error. Attaching to MonoDevelop didn’t give me a call stack but did raise the suspicion that a UnityEngine method was being called on a thread other than the main one, a suspicion that I thought might explain the 2 different callstacks .

As things were, the scene change was being handled by a method in a singleton “SceneChangeHandler” class, which in this case being called from within the OnCloseRequested function.

Instead, I’m now doing it by setting a flag in the SceneChangeHandler and then having it do the scene change on detecting the flag change in its Update() function, and that seems to be working.

As I understand it, this is now ensuring that the scene change is always being done on my main thread. It’s still not clear to me why there would have been a threading difference between the button-click and the time-out, given that as things were, OnCloseRequested was always being called in the same place within OnGUI (which I thought would have meant that it was always on the same thread).

So I’d still be very interested to know if anyone can shed any light on the difference between the first 2 callstacks above. Note that they are both from the Editor log, the only difference is that in one case the call happens as a result of a button press, and in the other (when it crashes) it happens without user interaction when the OnGUI method detects that an number of seconds have elapsed. Can it be that in the Editor this is causing the calls to happen on different threads?

Sorry if this isn’t very clear. Our scene handling system is kind of complicated!