Constant crashes when debugging

drawmaster77

Hey, once I upgraded to Unity 3.5 it now constantly crashes (99% of the time) when trying to debug photon code in monodevelop. Any ideas as to what it could be?

To replicate - open chatdemo application, place breakpoint somewhere in ChatPhotonClient, and run project couple times. The first time breakpoint will trigger, next time however when you restart execution Unity will crash.

Tobias

Do you stop and play, or just "resume" the demo?

We don't include debug symbols for the Unity libraries, so maybe this causes issues. We didn't extensively test the debugger (neither in 3.4 nor in 3.5).

Bankler

Have you made any progress on this since the question was asked by the topic starter? I'm also using MonoDevelop, and I get constant crashes when using Photon, as soon as I set a breakpoint (EDIT: Sorry, this is not what causes it, see reply below!). Only way I can debug is by using Debug.Log() and DebugConsole.Log(). (The last one is a third party thing, very recommended btw).

If start my game with the debugger attached, then set a breakpoint in some Update()-function, everything works fine. I can add additional breakpoints, press F5 to continue, and all that good stuff. However, if I press the play button again (to stop, that is), and then one more time to restart the game, Unity crashes.

Bankler

Instead of just complaining, I thought I could try to be of some help instead. In the following tests, I tried to find a workaround for using the debugger with what we have today. I also tried to find the exact condition for the crash to happen. Fortunately (and to admit, a little unexpected) I found a pattern that seems to be logical and 100% reproducable.

Okay, here we go.

Unity: 3.5.2f2
Photon: 1.14 (08. May 2012)

PART A: These tests performed without using any breakpoints.

A1. Attach debugger. Start game. Quit game. Start game. Crash.

A2. Attach debugger. Start game. Quit game. Detach. Re-attach. Start game. Crash.

A3. Start game. Attach debugger. Detach. Quit game. Start game.

No crash. Did repeat six cycles, still not having a crash.

A4. Start game. Attach debugger. Quit game. Detach. Start game.

No crash. Did repeat several times, no crash.

A5. Attach debugger. Start game. Detach. Quit game. Re-attach. Start game. Crash.

A6. Attach debugger. Start game. Detach. Quit game. [Start game. Re-attach. Detach. Quit game.] [Start game. Re-attach. Detach. Quit game.]

No crash. Note the start, and then transfering to another cycle.

Observations A:

Unity crashes if the debugger is attached when starting the game (case A1, A2, A5). However, it does NOT crash the first time, regardless if the debugger is attached or not (as seen in A6). Since I'm talking to a programmer, let's explain it like this.

private bool isFirstStart = false;
private bool isDebuggerAttached;

void RunUnity(){
	if(!isFirstStart)
	{
		if(isDebuggerAttached)
			Crash();
	}
	
	isFirstStart = true;
	RunUnityAsIntended();
}

---

PART B: Now adding breakpoints while testing. Will base tests on the previous succesful workarounds, A3, A4 and A6.

B1 (A3 style, but with breakpoints). Start game. Attach debugger. Set breakpoint in Update(). F5. F5. Delete breakpoint. F5. Detach. Quit game. Start game.

No crash! Yay!

B2 (A4 style, but with breakpoints). Start game. Attach debugger. Set breakpoint in Update(). F5. F5. Delete breakpoint. F5. Quit game. Detach. Start game.

No crash! Yay! (The differance from B1 is that we quit the game before detaching the debugger)

B3 A6 style, but with breakpoints). Attach debugger. Start game. Set breakpoint in Update(). F5. F5. Delete breakpoint. F5. Detach. Quit game. [Start game. Re-attach. Set breakpoint in Update(). F5. F5. Delete breakpoint. F5. Detach. Quit game.] [Start game. Re-attach. Set breakpoint in Update(). F5. F5. Delete breakpoint. F5. Detach. Quit game.]

No crash! Yay! (The differance from B1 is that we now started with the debugger attached on the first run)

Observations B:

So far, breakpoints doesn't have anything to do with the crashes. It still crashes on the same conditions as before.

---

PART C: Now I will never remove any breakpoints. Just leaving them in there until the next run.

C1 (A4 style, but with breakpoints left in place). Start game. Attach debugger. Set breakpoint in Update(). F5. F5. Detach. Quit game. Start game. Re-attach. F5. F5. Detach. Quit game.

No crash. Mono-develop complains "The VM is not suspended" several times. This seems to be okay to just ignore and move on.

C2 (A6 style, but with breakpoints left in place). Attach debugger. Start game. Set breakpoint in Update(). F5. F5. Detach. Quit game. [Start game. Re-attach. Set breakpoint in Update(). F5. F5. Detach. Quit game.] [Start game. Re-attach. Set breakpoint in Update(). F5. F5. Detach. Quit game.]

No crash. Same "The VM is not suspended" as in C1.

Observations C:

Breakpoints seem to be okay to leave in place while detaching the debugger and quitting and restarting and so on. Mono-develop gets really upset about it though. It is not possible to quit the game when it's stopped on a breakpoint (obviously).

---

Conclusions:
The pattern discovered in Part A seems to be correct. Part B and C didn't change much.

For the users:
Workaround ( "How to use the MonoDevelop debugger with Photon until there is a real solution to the problem"):
Attach the debugger AFTER starting the game. Detach it before you start the game again (preferably before even quitting it, so you don't forget, but it's your choice).

Never start the game with the debugger attached (though it seems to be okay first time... for some reason). It should be mentioned that I have not throughly tested if this workaround works 100% of the times. Please let me know how it works for you.

For Unity and/or Photon devs:
I hope these tests and conclusions will be of use for you when you attempt to find this bug. It should be possible to leave the debugger attached to the Unity process at all time without a crash. Currently it always crashes if the game is started with the debugger attached and it's not the first time you start the game.

Tobias

Thanks Bankler for writing this up into a useful guide!
It's always a bit tricky to pause the executing code because that usually means a timeout of the connection. Glad you could do it anyways.

When we have some time, we will see if we can enhance the lib in one way or another to make crashes less of a problem.

alexkring

Has this bug been fixed? Are there any updates on workarounds? I am currently using Unity 3.5.6, and I still experience this problem. Additionally, the workaround described above still results in a crash for me. Any information is appreciated, thank you!

-Alex

Tobias

No news.
This wasn't high prio as we thought the workaround is ok. I'm sorry to read it's not.
Maybe I can spend some time on it soon but that doesn't mean it will be fixable (if it depends on Unity).