koobas.hobune.stream
Multithreading - Freeze on Second Play
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?
Have the exact same problem. I have a few background threads in my app, though marked as IsBackground=True. Did you find any solution to this? I had some threads earlier and it worked fine, but after rewriting my background thread loop something went wrong. Doesn't help to attach debugger either, no useful info (not even thread names) on pause in debugger.
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.
There is nothing at the link anymore :( I'm facing a similar problem, so I was looking forward to get some ideas.
Thank you for letting me know. Sync issue when I moved blog last time. I've manually added this blog post back now.
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 ^^.
Thanks for updating the link! The blog post was interesting, especially the Parallel Stacks View.
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?
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
Had the same issue. In my case a Socket connection was still open.
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
This solved my problem. Closed the socket and it worked perfectly. Thanks :)
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.
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.
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.
Leaving resources allocated is a bad idea, sooner or later it will cause issues. Always try to release resources, especially files and threads.
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
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.
