STOP FREEZING/HANGING UNITY!!!

Oh, no no. I wasn't trying to make it seem like you were disputing lol. I was just trying to do the same. My error can't be an infinite loop.. As for his, I don't know. I've read through about 4-5 different posts now on the issue, and most people are learning toward it being a shader compilation issue.. Any thought on this eric?

 

I understand the point, my issue lies in the that I have 2 other functions, non-unity (per the applications I listed that I run) throughout the day to perform. I cannot transfer my other functions to a much slower machine (especially one that isn't portable). I could hold off on all Unity development until the evening however then I would be just as productive in Unity as I am now :-(

But, for the sake of protecting my investment, and UT's inability to work with me to solve this (because lets face it, the ONLY communication I've gotten about this issue is on this thread), I will ONLY use Unity on my mac mini to see if the problem persists. My guess is that it wont, and that UT will insist it's an issue with my machine in which I will gladly point, again, to the hundreds of other apps that do not freeze or hang. Perhaps I have some unique environment that Unity Editor cannot account for, which would speak more about Unity Editor than my machine...

 

Another idea for the sake of isolating the issue would be to use MonoDevelop instead Visual Studio. You don't have to like MonoDevelop, but you may find out whether it is related to the freezing or not.
Another possible cause for this might be editor scripts or scripts with [ExecuteInEditMode]. It is pretty easy to have something there which freezes Unity.

It might certainly be some kind of hardware or driver issue as well.

 

Out of curiosity, have you tried my suggestion of connecting the debugger and pausing execution after a lock-up? It has helped me find the source of several sources of lock-ups before. If you are lucky, it will be in managed land and you'll get a stack trace. If not, no harm done at least.

 

yes, I posted about this earlier. I will try to connect the debugger BEFORE the lockup and have it watch while I work to see if the lockup reveals anything.

 

Well, lets be honest, although I appreciate the help, having to try random things will result in a full time job of testing this for the next month. I don't think that using Visual studio or Monodevelop are hinged on how the editor recompiles the scene/project.

As for your second suggestion, I had thought the same. I already removed NGUI over a month ago (yeay unity UI is finally out) and will be removing Playmaker (not using it, not even sure why I have it loaded) however we use a few other plugins like photon, so having to remove everything will require a complete restructuring of the project as there are currently dependencies. BUT it's worth noting that I am working with a semi-empty scene. I have 2 scripts attached to a "Game" object in the scene. When the game starts, it loads up all prefabs into a pool, spawns what it needs to from that, and all the logic works from behind the scenes. I only use monobehaviours as markers to GameObjects, and I only record components that I may need to work with on Awake(). So most of the game is handled virtually in non-monobheaviours leaving Unity to only do what it does (Should do) best. My issue is whenever the little spinner in the lower right hand corner of the window starts spinning. I sit there and clench my butt cheeks and cross my fingers hoping it doesn't pause during spin. When it goes away, I sigh a big breath of relief. When it pauses, if fuels a fiery "Unity Rage" (copyright) :-(

 

Ah, yeah, sorry, I missed your post somehow. Yeah, try connecting to "Unity Editor (Unity)" before the lockup and see what happens if you pause it after. Although, since it happens during compilation, I'm not particularly confident it will tell us anything. :-/

 

I haven't used UnityVS, but I read that the script compilation in Unity is faster when UnityVS is used. I don't know whether this is true, but if it is, it clearly interferes with Unity at a very low level which might possibly lead to really hard to find issues. That may even become harder to isolate across different operating systems.
It was not just a random guess. As UnityVS directly interferes with Unity (even if you take the compilation thing away), it makes it an obvious candidate for the issue.

 

Yeah, I understand what your saying, and based on what you've heard it would be very logical. Although I haven't dissected UnityVS I don't think it makes compilation any quicker (at least nothing to which I've noticed). The only reason I use it is to create the VS project with all the references linked (UnityEngine.dll, UnityEditor.dll, etc). Having to manually link those each time I reopen the project is a pain.

BUT, looking back, I haven't been using UnityVS for very long. Looks like I installed UnityVS on 7/28/14 and I began having this issue around 9/20/14 (and it seems to be getting progressively worse as time goes on). So it's worth trying now that you mention it more.

 

I've had these hangs and crashes ever since I started trying out Unity last winter. It has always happened with every version. Now on 4.6 RC2. I almost always dismiss the bug reporter that pops up because I figured it just is buggy and people work with it that way. Lol For me, one way I can almost always produce the hang and crash is by having Unity open, a prefab with sprite renderer selected and then go outside Unity launch Paint Shop Pro or basically any graphics editor, load the image (sheet) the sprite renderer is using, make a change and save the image. It seems to be something to do with the importing (or auto-reimporting) of assets. So I just changed workflow. Close unity before making even the slightest graphic update.

 

I had some hangs with the older UnitVS. The new version fixed a lot of hangs for me.

Anyway, I see you have already tried attaching the debugger to the unity process (I'm curious what you get while attaching to the mono land). So is the last line from the call stack most recent one? If yes it looks like some external dynamic library.

 

I just restarted the mac and did a 2 hour full diagnostic (includes memory burnin) and everything came out clean. going to work with the monodevelop process watcher now.

 

Ugh, I cannot possibly imagine having to work like that, being able to just change graphical assets is quite a useful part of the workflow!

 

Oh yeah I agree it would be awesome to be able to update "on the fly" but about 80% of the time it produces a hang then crash. The roughly 20% of time it doesn't is great but cannot be relied on. Maybe it has something to do with timing. Like the file is being written out and Unity tries to open and read it in but file is still locked by the paint program's save process. Or maybe the meta data is causing the issue. Perhaps it no longer matches the actual file in some way. Not sure what is stored in the meta files so no idea if that could be the cause or not. But anyway, I don't want to hijack the thread. Just wanted the OP to know certainly others encounter the hangs and crashes. It is real.

 

All I can say is that this is not normal, just like the OP's crash is definitely not normal. Our workflow here involves updating assets in the background all the time, we almost never quit to pull updates from the repository, Unity just detects the changes and reimports what needs reimporting, even scenes!

If you enable textual meta files you can have a look. For assets that are imported using some sort of importer, such as images, models, etc. the meta file contains the GUID of the asset and any importer settings you have made, so that they stick if the file is overwritten. This effectively facilitates exactly the workflow that is crashing for you!

I actually think you should open a separate thread and submit a bug report as well, your crashes are definitely serious enough.

 

So many software products have issues like this (heck even some physical products) that I just accept it and try to find workarounds for the issues. There is almost always a bug or a hundred and it takes more time to try to resolve the issue with the developer(s) than it does to find a work around. As long as I can close Unity, make any graphics updates, open Unity and it all works fine I can work with that. Sure it would be cool to have the "live update" work flow but I see it more as a bonus than a necessity.

 

I just wanted to add that I am seeing the exact same issues and posted about it here: http://forum.unity3d.com/threads/unity-editor-4-x-osx-hanging-on-compile-1-in-3-times.283400/ I got a crash one time it locked up so a crash log is included! This is very frustrating and slows down development quite a bit!

 

The monodevelop attach to process was a bust :-( All that happened is when Unity Editor hangs, so does monodevelop :-(

 

Can you click the Play button and play your game at all?

I found that my issue is a memory leak. When I start the editor, if I look at my task manager, Unity.exe hangs at around 140,000K memory. When I click play and start a game, it goes up to around 300,000K memory. When I stop Play mode, it doesn't decrease at all. If I start Play mode again, it hangs because of the high amount of memory it is already taking up.

 

When it hangs, I cannot do anything except sit and watch the spinner. In the past, I thought it just needed to chug through something, so I let it run for a few hours while I ran errands. Came back 5 hours later and it was still just spinning away...

 

I would try to attach the debugger to the Unity process and get the call stack (assuming you haven't done this already in previous page of this thread) and also to the MonoDevelop and get the call stack.

What I think the Epictickle was saying is to try to run clean instance of Unity and watch the memory consumption of the process if there aren't any leaks with player.

 

That's exactly what I was saying. If you are able to enter play mode at least once, on the first play, then it is probably a memory leak. That is exactly what is happening to mine. You can tell if it is by watching your Task Manager. In my build, I am able to play the first time around. Then, the second time it will hang because Unity is not garbage collecting something that it should be. Something is hanging around in memory after play mode... Something huge.

 

Yeah, did that, Monodevelop just hangs then.

As for clean instance; there are times I wont even hit play once (just updating scripts, going back to unity to compile to make sure everything is kosher, back to visual studio, rinse repeat, freeze).

 

3 months later, this is the official response:

Discouraged, but fully resolved mentally, my response was:

Perhaps I'm pushing Unity too hard. Perhaps I should just limit the Unity to very simple non-production applications. Oh well. Time to move on and consume alcohol during periods of high hang/crash to remove the frustration

 

Update: New macbook pro, new project (simple to, like 15 scripts) and it still freezes on compile at times....

 

Post that project, I'm kinda interested in what you've cooked up that made Unity hate your rig so much 8-}..

 

I can share the code if you like, unfortunately the art is under NDA :-(

 

Having a similar problem with hangs when recompiling mostly (latest Unity 5, been having this problem since early 4.x). Always happens on MonoManager ReloadAssembly, and the thread report looks a lot like what you have:

Code (csharp):

1.  
2.  11  MonoManager::BeginReloadAssembly(DomainReloadingData&) + 2053 (Unity + 7461333) [0x10071d9d5]
3.  
4.   11  UnloadDomain() + 103 (Unity + 7474311) [0x100720c87]
5.  
6.   11  ??? (<BEA38B5E-91C0-3C8D-ABCC-EB17258995F2> + 784253) [0x10569d77d]
7.  
8.   11  ??? (<BEA38B5E-91C0-3C8D-ABCC-EB17258995F2> + 785756) [0x10569dd5c]
9.  
10.   11  ??? (<BEA38B5E-91C0-3C8D-ABCC-EB17258995F2> + 1597331) [0x105763f93]
11.  
12.   11  ??? (<BEA38B5E-91C0-3C8D-ABCC-EB17258995F2> + 1537970) [0x1057557b2]
13.  
14.   11  ??? (<BEA38B5E-91C0-3C8D-ABCC-EB17258995F2> + 1537839) [0x10575572f]
15.  
16.   11  __psynch_cvwait + 10 (libsystem_kernel.dylib + 90422) [0x7fff8e524136]
17.  
18.  *11  psynch_cvcontinue + 0 (pthread + 26908) [0xffffff7f80ee391c]
19.  

I've been trying to figure out what causes it, but haven't found anything consistent. From what I've read in other topics the ReloadAssembly is waiting for another thread, which never ends. I have no idea how to read the mac os x reports though, so I'm basically flying blind in that regard.

 

Hang on guys, just a quick question here, are you running *any* code that runs background .Net threads? If so, unless you have code to manually terminate those threads, Unity will lock up on BeginReloadAssembly(). Forcing the threads to stop OnAssemblyLoad and OnDomainUnload helps. Any threads waiting will have to be signaled to quit.

Until I got my threaded networking code to terminate gracefully, I had a hotkey for quit-restarting Unity...

 

I am not doing any Thread stuff. Just Coroutines. I've been trying to figure out if perhaps Coroutines could cause things like this, but I haven't had any luck making a consistent case for it. I've been putting Debug.Log's on every StartCoroutine and at the end of it.

The only Coroutines that don't Debug.Log their end are situation such as these, where it will run until the Application is stopped:

Code (CSharp):

1.  
2. IEnumerator SomeCoroutine()
3. {
4.     while( Application.isPlaying ) yield return null;
5.     Debug.Log( "END" );
6. }
7.  

I've also had situations like these, but I've implemented code to make sure they always stop, and it hasn't helped either:

Code (CSharp):

1.  
2. IEnumerator SomeCoroutine()
3. {
4.     running = true;
5.     while( running ) yield return null;
6.     Debug.Log( "END" );
7. }
8.  

 

Are any of you also using UnityVS?

I have the hang in an empty project with 1 scene, 1 empty monobehaviour, and UnityVS. Combinations of opening scenes, triggering recompiles and starting/stopping cause the hang.

EDIT: Note that I'm using OS X, but have UnityVS 2012 in my project because I also work on Windows, and the whole project is synced over SVN.

Reported as case 689564

 

I'm also getting intermittent hangs, most often when pushing run. The main stack is also calling UnloadDomain() like the others posted here.

* thread #1: tid = 0x23d51b, 0x9117a7ca libsystem_kernel.dylib`__psynch_cvwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x9117a7ca libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x9b571d1d libsystem_pthread.dylib`_pthread_cond_wait + 728
frame #2: 0x9b573bd9 libsystem_pthread.dylib`pthread_cond_wait$UNIX2003 + 71
frame #3: 0x04527b22 libmono.0.dylib`_wapi_handle_timedwait_signal_handle + 455
frame #4: 0x04527bcd libmono.0.dylib`_wapi_handle_wait_signal_handle + 46
frame #5: 0x0453739d libmono.0.dylib`WaitForSingleObjectEx + 569
frame #6: 0x0445d630 libmono.0.dylib`mono_domain_try_unload + 503
frame #7: 0x0445cf8c libmono.0.dylib`mono_domain_unload + 39
frame #8: 0x0095c4e1 Unity`UnloadDomain() + 113
frame #9: 0x00959ad3 Unity`MonoManager::BeginReloadAssembly(DomainReloadingData&) + 2019
frame #10: 0x0095ab08 Unity`MonoManager::ReloadAssembly(dynamic_bitset, bool) + 40
frame #11: 0x0120dfd3 Unity`ReloadAllUsedAssemblies() + 195
frame #12: 0x014c356c Unity`Application::SetIsPlaying(bool) + 716
frame #13: 0x014c2d91 Unity`Application::TickTimer() + 2289
frame #14: 0x016b4c38 Unity`-[EditorApplication TickTimer] + 24
frame #15: 0x9246b9cb Foundation`__NSFireTimer + 117
frame #16: 0x965faea6 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
frame #17: 0x965fa863 CoreFoundation`__CFRunLoopDoTimer + 1395
frame #18: 0x9667506d CoreFoundation`__CFRunLoopDoTimers + 349
frame #19: 0x965b2353 CoreFoundation`__CFRunLoopRun + 1779
frame #20: 0x965b19ea CoreFoundation`CFRunLoopRunSpecific + 394
frame #21: 0x965b184b CoreFoundation`CFRunLoopRunInMode + 123
frame #22: 0x9190ab5d HIToolbox`RunCurrentEventLoopInMode + 259
frame #23: 0x9190a8e2 HIToolbox`ReceiveNextEventCommon + 526
frame #24: 0x9190a6bd HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 92
frame #25: 0x945fe349 AppKit`_DPSNextEvent + 1602
frame #26: 0x945fd870 AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 119
frame #27: 0x945f015c AppKit`-[NSApplication run] + 727
frame #28: 0x945d8ff8 AppKit`NSApplicationMain + 1165
frame #29: 0x016ca38b Unity`EditorMain(int, char const**) + 1339
frame #30: 0x016caac8 Unity`main + 24
frame #31: 0x000037b5 Unity`start + 53

 

Woah, sorry to necro this thread, but it's just unbelievable that we're experiencing this issue since 2014 and it's still there.

For me it has been quite an intermittent thing: it can perform well for weeks and then start freezing almost every time you push "Run", for other several weeks. Started with Unity 4.x and still present in 2018.3.8f1, despite changing PC (I'm on Windows).

 

The original complaint was memory usage causing slowdowns. This was solved in Unity 5 when it went to 64bit.
If you're seeing issues freezing/pausing make sure you have enough memory. Also, look through your project and remove all your unneeded assets, as every time you press run or change a file, your assets have to be reloaded into memory.

 

Yea, as noted above, different issue. Closing for unrelated necro.