Multithreading - Freeze on Second Play

Question

Everything works fine when clicking Play the first time. After stopping once, pressing the play button again (or closing the editor) results in Unity freezing; I must close Unity via TaskManager. When reloaded it then works again, once, at which point I must repeat the process.

I assume this is being caused by threads/sockets remaining active after stopping the program in the Unity editor. Is there a way to determine which thread(s) / what is causing the problem?

Answer 1

Answer by tedd-hansen · Oct 09, 2016 at 03:18 PM

For anyone coming here to find a solution.

I have written a blog post with some pointers on how to debug this issue: http://blog.tedd.no/2016/10/09/investigating-unity-hang-on-second-run-multi-threading/

There are probably multiple reasons for this to happen, but I have encountered two so far:

Failure to shut down background threads.
A destructor (finalizer) that hangs (deadlocked).

Connecting Visual Studio to Unity.exe through "Debug->Attach to process..." (not "Attach to Unity"), pausing it and looking at Parallel Stacks (Debug->Windows->Parallel Stacks) can give you some insights into whats going on.

Edit: Since this writing I've also seen a recursive function lock up Unity. 16 levelx max breadth-first search type of function. No error, Just plain old hang. Changing the function to use a queue instead of recursion fixed it.

Add comment · Show 7 · Share

Harinezumi · Apr 05, 2017 at 07:13 AM 0

Share

There is nothing at the link anymore :( I'm facing a similar problem, so I was looking forward to get some ideas.

tedd-hansen · Apr 05, 2017 at 08:50 AM 1

Share

Thank you for letting me know. Sync issue when I moved blog last time. I've manually added this blog post back now.

Bunny83 tedd-hansen · Apr 05, 2017 at 11:05 AM 0

Share

btw: It's called a destructor not a deconstructor. It becomes even more confusing since C# 7 now has a feature called "deconstructor"- However it has a completely different meaning. You may want to correct your blog post as well as your answer ^^.

tedd-hansen Bunny83 · Apr 06, 2017 at 09:37 AM 0

Share

Thanks, updated.

Harinezumi tedd-hansen · Apr 05, 2017 at 11:37 AM 0

Share

Thanks for updating the link! The blog post was interesting, especially the Parallel Stacks View.

Aminushki · Apr 17, 2017 at 05:44 PM 0

Share

What do you mean by "I did a system wide search for ~ (destructor) and removed all of them (just for testing)." ? Like a file search in This PC?

tedd-hansen Aminushki · Apr 17, 2017 at 06:08 PM 0

Share

Search all files in project for "~" (tilde) (or even better, regex search for "^\s*~") without the double quotes. That will give you a list of all places where you have a destructor (in C#). If you haven't implemented these then they are likely not the problem. A destructor looks like "~ClassName() { Code... }", see https://msdn.microsoft.com/en-us/library/66x5fx1b.aspx

Answer 2

Answer by eco_bach · Jan 30, 2017 at 01:45 AM

Had the same issue. In my case a Socket connection was still open.

Add comment · Show 3 · Share

Lythox · Nov 09, 2017 at 06:46 PM 0

Share

Same for me. I also didnt ever dispose of the threads though so that might have been the issue too. Strangely enough this has worked fine for my $$anonymous$$acBook but on Windows I suddenly got the second time play freeze

dhruvmg · Feb 01, 2018 at 01:57 PM 0

Share

This solved my problem. Closed the socket and it worked perfectly. Thanks :)

darvath · Mar 31, 2018 at 04:15 PM 0

Share

     private void OnApplicationQuit()
     {
         socket.Close();
     }

If you are using Socket.io then make sure to close the connection like above. I had the same issue as Lythox, on my $$anonymous$$acBook everything worked perfectly, but on Windows I couldn't proceed unless I restarted my server.

Answer 3

Answer by VanZeebroeck · Dec 16, 2014 at 10:03 AM

I had this same issue. And my problem was that the threads were still running while I pressed stop/closed the editor.

Make sure your threads are all shutdown, maybe by implementing a stop-all-threads-button that you press before pushing the stop button in the editor.

Add comment · Show 2 · Share

EyePD · Jan 13, 2020 at 03:00 PM -1

Share

I've found that threads can be left running; I attached a Visual Studio debugger to my Unity instance and was able to breakpoint inside my thread code. I think it's much better to make sure you clean up your threads but if you want to leave them running you should have some logic in your plugin to make sure they're not re-created each time you hit play.

Harinezumi EyePD · Jun 01, 2020 at 03:37 PM 0

Share

Leaving resources allocated is a bad idea, sooner or later it will cause issues. Always try to release resources, especially files and threads.

Answer 4

Answer by jethrogillgren · Jan 19, 2018 at 08:18 AM

If you write any Destructors, they get called on the NEXT time you press play. Just before your new instances are constructed. It can confuse your debugging no end. I've had a few issues with every 2nd play crashing, and it's always been to do with cleaning up / closing objects correctly. This was seen on 2017.2

Add comment · Share

Answer 5

Answer by EyePD · Jan 13, 2020 at 03:02 PM

Using a callback to forward debug output from a plugin into the Unity log can in some cases cause a hang on second run. See this forum post for more details.

Add comment · Share

Multithreading - Freeze on Second Play

6 Replies

Your answer

Follow this Question

Related Questions