4.1: Freeze after Application.LoadLevel (OS X Standalone)

(Case 534025)

I am pretty sure this is new to 4.1. Calling either LoadLevel or LoadLevelAsync results in my standalone build hanging. It does work once, but subsequent loads cause the game to freeze (spinny wheel of death). This is a large project with lots of resources, and this was working prior to upgrade. Seems to be stuck on some GC business.

So far, my only repro case is the game project itself, so I am starting here. Anyone else having problems loading levels in standalone after upgrading?

Dumpy below.

---

OS Version: 10.6.8 (Build 10K549)
Architecture: x86_64
Version: Unity Player version 4.1.0f4 (4.1.0f4)

Code (csharp):

1. start + 40 (in Zigfrak) [0x2108c]
2. _start + 208 (in Zigfrak) [0x2115d]
3. PlayerMain(int, char const**) + 610 (in Zigfrak) [0xa4b322]
4. NSApplicationMain + 574 (in AppKit) [0x98488289]
5. -[NSApplication run] + 821 (in AppKit) [0x984901f3]
6. -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156 (in AppKit) [0x984cddd6]
7. _DPSNextEvent + 847 (in AppKit) [0x984ce595]
8. BlockUntilNextEventMatchingListInMode + 81 (in HIToolbox) [0x98f3ca3e]
9. ReceiveNextEventCommon + 354 (in HIToolbox) [0x98f3cbb9]
10. RunCurrentEventLoopInMode + 392 (in HIToolbox) [0x98f3ce04]
11. CFRunLoopRunInMode + 97 (in CoreFoundation) [0x950d91f1]
12. CFRunLoopRunSpecific + 452 (in CoreFoundation) [0x950d93c4]
13. __CFRunLoopRun + 8059 (in CoreFoundation) [0x950dba3b]
14. __NSFireTimer + 141 (in Foundation) [0x93028484]
15. -[PlayerAppDelegate UpdatePlayer] + 224 (in Zigfrak) [0xa4bc70]
16. PlayerLoop(bool, bool, IHookEvent*) + 331 (in Zigfrak) [0x7a4aab]
17. PreloadManager::WaitForAllAsyncOperationsToComplete() + 111 (in Zigfrak) [0x7a89bf]
18. PreloadManager::UpdatePreloadingSingleStep(bool) + 232 (in Zigfrak) [0x7a7b58]
19. PreloadLevelOperation::IntegrateMainThread() + 525 (in Zigfrak) [0x7a990d]
20. PlayerLoadLevelFromThread(int, std::string const, AwakeFromLoadQueue) + 39 (in Zigfrak) [0x7a2857]
21. LevelLoading::LoadLevel(int, std::string const, AwakeFromLoadQueue) + 1448 (in Zigfrak) [0x7a24b8]
22. CleanupAfterLoad() + 18 (in Zigfrak) [0x7cfed2]
23. GarbageCollectSharedAssets(bool) + 889 (in Zigfrak) [0x79d549]
24. MarkAllDependencies(GarbageCollectorState) + 2676 (in Zigfrak) [0x79ca74]
25. ReadObjectFromPersistentManager(int) + 38 (in Zigfrak) [0x499ed6]
26. PersistentManager::ReadObject(int) + 394 (in Zigfrak) [0x86f47a]
27. AwakeFromLoadQueue::PersistentManagerAwakeSingleObject(Object, TypeTree*, AwakeFromLoadMode, bool, void (*)(Object, TypeTree const)) + 46 (in Zigfrak) [0x86578e]
28. Unity::GameObject::AwakeFromLoad(AwakeFromLoadMode) + 26 (in Zigfrak) [0x4a8fba]
29. Unity::GameObject::SetSupportedMessagesDirty() + 44 (in Zigfrak) [0x4a780c]
30. Unity::GameObject::GetSupportedMessagesRecalculate() + 235 (in Zigfrak) [0x4a76bb]
31. ReadObjectFromPersistentManager(int) + 38 (in Zigfrak) [0x499ed6]
32. PersistentManager::ReadObject(int) + 326 (in Zigfrak) [0x86f436]
33. SerializedFile::ReadObject(long, int, ObjectCreationMode, bool, TypeTree**, bool*, Object**) + 892 (in Zigfrak) [0x876dec]
34. MonoBehaviour::VirtualRedirectTransfer(StreamedBinaryRead<false>) + 51 (in Zigfrak) [0x7d8993]
35. void MonoBehaviour::TransferEngineAndInstance<StreamedBinaryRead<false> >(StreamedBinaryRead<false>) + 226 (in Zigfrak) [0x7f95d2]
36. MonoBehaviour::SetScript(PPtr<MonoScript> const, MonoObject*) + 52 (in Zigfrak) [0x7fe774]
37. MonoBehaviour::RebuildMonoInstance(MonoObject*) + 408 (in Zigfrak) [0x7fe2d8]
38. scripting_object_new(MonoClass*) + 26 (in Zigfrak) [0x817b1a]
39. mono_object_new_specific + 290 (in libmono.0.dylib) [0x1517718]
40. mono_object_new_alloc_specific + 93 (in libmono.0.dylib) [0x15175bd]
41. GC_malloc + 79 (in libmono.0.dylib) [0x159b4ed]
42. GC_lock + 27 (in libmono.0.dylib) [0x15a052e]
43. semaphore_wait_signal_trap + 10 (in libSystem.B.dylib) [0x96500b42]
44.  
45.  

 

Just me? Really?

Verified that this is still happening under 4.1.1.

 

We have been having a similar issue, but we are experiencing it on Android builds with 4.1 and 4.1.1. We are still investigating but the logcat is not outputting any errors and the application just goes into a hung/waiting state. It only happens on some of our larger scenes, our smaller scenes tend to load alright but we have a handful of bigger levels that just hang upon attempting to load into them.

The game works fine within 4.0/4.0.1, will report if we find any more info.

 

Sounds similar... who knows.

The project folder is huge, but I've sent in a bug report with an attached dev build. Will see what happens.

 

Same here while building for iOS. The project worked with Unity 4.0 and stopped working as soon as I upgraded to 4.1.1. Upgrading to 4.1.2. didn't help. I'm afraid I'll need to downgrade until this is fixed. Very bad for morale.

 

Confirmed that the problem occurs also with the OSX standalone player.

 

iaanus: Could you submit a case with the bug reporter? The more the merrier. Feel free to reference my case, 534025.

Any kind of response or acknowledgement from Unity would be swell.

 

As a possible workaround, I'm using LoadLevelAdditive rather than LoadLevel, and then destroying the old scene manually.

It's ugly, but so far it seems to effectively bypass whatever horrible brokenness is going on with LoadLevel in 4.1.

Would still love to see an acknowledgement and proper fix for this issue. Hope this helps.

 

Hooray! I'm not alone. I've been wrestling with this issue for the past week, and it's driving me insane. Unfortunately I don't have any solutions, but I'll add my test results to the collective pool in hopes it helps. Here's what I know:

* The problem occurs in Max OS X Standalones and in iOS apps. I haven't tested other platforms.
* In my project, the problem occurs after (1) a scene has already been loaded, (2) objects are instantiated over the network, and (3) Application.LoadLevel is called which results in the network objects being destroyed. I can load scenes any number of times without issue, but once I load a scene where network objects are created, the very next time Application.LoadLevel is called the problem will occur and the app will stall.
* As far as I can tell, the problem only occurs on the network clients.
* The problem occurs even when loading small or empty scenes. In fact, the smaller the new scene is, the more the problem happens. Loading larger scenes sometimes dodges the issue, but it's not a guarantee.

I'm working on a networked multiplayer project, and all Application.LoadLevel calls are triggered by RPCs. I haven't tested this on a single-player / offline app. Is your project single-player / offline? I've always suspected that the cause of this problem is network-related, but you didn't mention anything about a network in your posts so now I'm beginning to think it's more of a purely Application.LoadLevel bug.

 

This particular project is single player. The problem seems related to how Unity *unloads* scenes. Some GC lock condition is getting tickled on Darwin (iOS/OSX).

Again, using LoadLevelAdditive instead, and removing the old scene contents manually, has allowed me to work around this. It did take a bit of reorganizing, but I'm back up and running. I can load levels all day long now.

Please file a case with the bug reporter! Something is seriously broken here, and I don't think Unity believes me.

 

Yep - I've just wasted 2 days uncovering this exact same bug in unity. It works OK in the editor, and the problem manifests on iOS devices.
Likewise I found a workaround by manually deleting the level contents and using LoadLevelAdditive, but now I think I'm just going to roll back to 4.0 until they fix this. I will file a bug report and mention your case number.

 

An update to my previous post, we did chase down the issue to a very strange case that was causing the failure for us and have submitted it as case #535468 and have currently just been working under 4.0.3 as the issue is a fairly large wrench in our works.

On a high level, we tracked it down to a custom script attached to a prefab with a old style particle emitter strapped to it, the GO itself was parents to a another GO which is then referenced on a script of one of our character assets so, when we called Resources.load on certain characters, some even being identical copies of each other, following a scene change, it would cause the hang.

Remove that custom script (and we tested it as literally nothing more then a name that inherited from a monobehavior with no actual code) on the particle emitter, and it works fine every time, however, this is not something we can easily remove as it controls certain aspects of when and how we handle particles and recycling.

I can get the test project we had together and post it if anyone is interested.

 

We are encountering this issue exactly as described ( on iOS ). Definitely happened after upgrading to 4.1, code in question hasn't changed.

Code (csharp):

1.  
2. 0   0x35c550fc in __psynch_mutexwait ()
3. 1   0x3402c128 in pthread_mutex_lock ()
4. 2   0x0152114c in GC_generic_lock ()
5. 3   0x015211a4 in GC_lock ()
6. 4   0x0151bb14 in GC_gcj_malloc ()
7. 5   0x014b6abc in mono_object_new_alloc_specific ()
8. 6   0x014b6c64 in mono_object_new_specific ()
9. 7   0x014baf08 in mono_object_new ()
10. 8   0x014caaec in mono_type_get_object ()
11. 9   0x014b9c18 in mono_class_vtable_full ()
12. 10  0x014baefc in mono_object_new ()
13. 11  0x011130d8 in scripting_object_new(MonoClass*) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Scripting/Backend/Mono/ScriptingBackendApi_Mono.cpp:119
14. 12  0x01109404 in MonoBehaviour::RebuildMonoInstance(MonoObject*) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Mono/MonoBehaviour.cpp:1546
15. 13  0x011095b8 in MonoBehaviour::SetScript(PPtr<MonoScript> const, MonoObject*) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Mono/MonoBehaviour.cpp:1597
16. 14  0x010f7edc in void MonoBehaviour::TransferEngineAndInstance<StreamedBinaryRead<false> >(StreamedBinaryRead<false>) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Mono/MonoBehaviourSerialization.cpp:734
17. 15  0x010f771c in MonoBehaviour::VirtualRedirectTransfer(StreamedBinaryRead<false>) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Mono/MonoBehaviourSerialization.cpp:795
18. 16  0x01144138 in SerializedFile::ReadObject(long, int, ObjectCreationMode, bool, TypeTree**, bool*, Object**) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Serialize/SerializedFile.cpp:1319
19. 17  0x0113ea1c in PersistentManager::ReadObject(int) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Serialize/PersistentManager.cpp:1103
20. 18  0x00f811c0 in ReadObjectFromPersistentManager(int) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/BaseObject.cpp:225
21. 19  0x01054200 in PPtr<Unity::Component>::operator Unity::Component*() const at /Applications/buildAgent/work/7535de4ca26c26ac/./Runtime/BaseClasses/BaseObject.h:849
22. 20  0x00f86dc4 in ImmediatePtr<Unity::Component>::Load() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/BaseObject.h:157
23. 21  0x00f86db4 in ImmediatePtr<Unity::Component>::GetPtr() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/GameObject.cpp:173
24. 22  0x00f86da8 in ImmediatePtr<Unity::Component>::operator Unity::Component*() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/GameObject.cpp:216
25. 23  0x00f86da8 in Unity::GameObject::GetSupportedMessagesRecalculate() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/GameObject.cpp:354
26. 24  0x00f86498 in Unity::GameObject::SetSupportedMessagesDirty() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/GameObject.cpp:339
27. 25  0x00f86438 in Unity::GameObject::AwakeFromLoad(AwakeFromLoadMode) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/GameObject.cpp:103
28. 26  0x0113b034 in AwakeFromLoadQueue::PersistentManagerAwakeSingleObject(Object, TypeTree*, AwakeFromLoadMode, bool, void (*)(Object, TypeTree const)) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Serialize/AwakeFromLoadQueue.cpp:314
29. 27  0x0113ea48 in PersistentManager::ReadObject(int) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Serialize/PersistentManager.cpp:1109
30. 28  0x00f811c0 in ReadObjectFromPersistentManager(int) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/BaseObject.cpp:225
31. 29  0x012007c4 in PPtr<Unity::GameObject>::operator Unity::GameObject*() const at /Applications/buildAgent/work/7535de4ca26c26ac/./Runtime/BaseClasses/BaseObject.h:849
32. 30  0x011fb9e4 in ImmediatePtr<Unity::GameObject>::Load() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/./Runtime/BaseClasses/BaseObject.h:157
33. 31  0x011fb9d4 in ImmediatePtr<Unity::GameObject>::GetPtr() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/iPhonePlayer-armv7/Graphics.cpp:173
34. 32  0x011fb9c8 in ImmediatePtr<Unity::GameObject>::operator*() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/iPhonePlayer-armv7/Graphics.cpp:218
35. 33  0x011fb9c8 in Unity::Component::GetGameObject() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/iPhonePlayer-armv7/Graphics.cpp:327
36. 34  0x010dd59c in ProcessValidComponent [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/GarbageCollectSharedAssets.cpp:716
37. 35  0x010dd594 in ProcessTransform [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/GarbageCollectSharedAssets.cpp:723
38. 36  0x010dd594 in MarkAllDependencies [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/GarbageCollectSharedAssets.cpp:895
39. 37  0x010dd474 in GarbageCollectSharedAssets(bool) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/GarbageCollectSharedAssets.cpp:208
40. 38  0x010f3990 in CleanupAfterLoad() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/SaveAndLoadHelper.cpp:757
41. 39  0x010f3f9c in CompletePreloadManagerLoadLevel(std::string const, AwakeFromLoadQueue) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/SaveAndLoadHelper.cpp:938
42. 40  0x010e0c58 in LevelLoading::LoadLevel(int, std::string const, AwakeFromLoadQueue) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/Player.cpp:1214
43. 41  0x010e0a6c in PlayerLoadLevelFromThread(int, std::string const, AwakeFromLoadQueue) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/Player.cpp:337
44. 42  0x010e411c in PreloadLevelOperation::IntegrateMainThread() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/PreloadManager.cpp:761
45. 43  0x010e3444 in PreloadManager::UpdatePreloadingSingleStep(bool) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/PreloadManager.cpp:451
46. 44  0x010e3930 in PreloadManager::WaitForAllAsyncOperationsToComplete() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/PreloadManager.cpp:515
47. 45  0x010e3a38 in PreloadManager::UpdatePreloading() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/PreloadManager.cpp:538
48. 46  0x010e1b84 in PlayerLoop(bool, bool, IHookEvent*) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/Player.cpp:1579
49. 47  0x00ea9d30 in UnityPlayerLoop() at /Applications/buildAgent/work/7535de4ca26c26ac/PlatformDependent/iPhonePlayer/LibEntryPoint.mm:376
50. 48  0x00005060 in -[AppController Repaint] at /Users/justin/Projects/Unity/Current/Constructed/Builds/ios/ios/Classes/AppController.mm:342
51. 49  0x00004fc0 in -[AppController RepaintDisplayLink] at /Users/justin/Projects/Unity/Current/Constructed/Builds/ios/ios/Classes/AppController.mm:323
52.  

 

I've found that calling Resources.UnloadUnusedAssets() also triggers a freeze in my project on Mac, same basic symptoms.

Good times!

 

I'm also seeing this problem. I'm upgrading our projects from Unity 3.5.7 to 4.1. In our code, calling Resource.Load() on a prefab before loading a scene was what would cause this scenario. Not sure if it was something specific about that prefab or an issue with loading any resources but If we added the prefab to the first scene directly then everything worked fine.

Would love to see a fix for this!

 

Hi, we got the same here.
I'm trying to fix it removing 'Resources.UnloadUnusedAssets()'.

Waiting for an Unity update...

Edit :
All is working fine in the Editor and when I make a build (for IOS), the application sometimes stop loading levels.
The application don't load my levels only with one of my two characters (the user may choose one of two characters). It is really strange.
I have swapped the working and not working characters and finally, the character working before don't work and the one which was not working works perfectly....
So the bug don't come from my prefab initialization, I think it is a new Unity bug because everything was working perfectly before the patch

 

FYI, here's the code I've been using to work around this issue.

First, I use a simple script that I attach to all my gameobjects that I want to persist between levels:

Code (csharp):

1. #pragma strict
2.  
3. DontDestroyOnLoad(this);
4.  
5. @script AddComponentMenu ("Utility Scripts/Persist")

Then, in every script that used to call Application.LoadLevel() I replace it with a call to LoadLevelWorkaround(sceneName):

Code (csharp):

1. // Workaround function to avoid the Unity 4.1 bug that plagues Application.LoadLevel.
2. // This is done by manually removing all the old objects (unless they are set to Persist) and then loading the specified scene additively
3. function LoadLevelWorkaround(level : String)
4. {
5.     // Find all the game objects in the scene
6.     var allTransforms : Transform[] = FindObjectsOfType(Transform);
7.  
8.     // Cycle through them and delete everything that isn't set to Persist
9.     for(var i : int = 0; i < allTransforms.length; i++)
10.     {
11.         // Only look at the transform roots
12.         if(allTransforms[i])                                    // Make sure the object is still around (might not be the case of the transform was another child of a root that has already been destroyed)
13.         {
14.             var root : Transform = allTransforms[i].root;
15.             if(!root.GetComponent("Persist"))                   // The object is not set to Persist
16.             {
17.                 Destroy(root.gameObject);
18.             }
19.         }
20.     }
21.    
22.     // Additively load the specified level
23.     Application.LoadLevelAdditive(level);
24. }
25.  

 

Thanks gyst for the tip. Unfortunately, having to put Persist component all over the scenes is a bit too disruptive for my project. If only we could check for DontDestroyOnLoad in a simpler way... I just wish this bug could be fixed soon.

 

I used a similar solution without a component requirement- implemented a "destroy everything" method, which skips passed-in objects as well as those with a specially-named parent. It's so nasty that I am not going to post the code, for the public good.

Looking forward to being able to go back to doing this the "right" way. Joachim chimed in, which gives me a great deal of hope

 

I should have clarified that you only need to put the Persist.js onto the root game objects, not their children. Even so, it may not be ideal for all situations. Here's hoping the real fix makes it into the next Unity update!

 

Is this bug fixed yet? I am having the same exact problems...

 

I received word that this is fixed in the next release of Unity. Will see, I guess :-|

 

Alright, thanks for catching this (sorry you had to catch this!).

 

EDIT: Oops, didn't read the second page.

I'm having this in 4.1.2 (iOS and OS/X builds), any word on a when a fix might be available?

 

This is scary, but I'm not having this issue..how is possible ?
At least not on win32/mac build.

 

Thanks for everyone who has contributed to this thread. We've also been experiencing the LoadLevel and UnloadUnusedAssets crash/lockup's on iOS.

Some of our levels trigger the problem and others don't. Reading your posts I suspect some of our levels are loading a "problem" prefab. As people have mentioned, everything was working a few weeks back and everything works fine on PC. It's possible that we're loading a single prefab multiple times, I'm wondering if that might cause issue.

We're not currently using networked objects.

 

I tried the "delete all the objects and then load additively" workaround, but load additive doesn't work with nav meshes. So that particular workaround can't be used for those of us that need nav meshes.

 

Two months have passed and still no fix is to be seen. That's very bad. I understand that the new release is introducing new features and that it's taking longer than planned, but this is a show-stopper bug: Unity 4.1.2 is NOT USABLE as-is on iOS and Mac. Having a convoluted work-around doesn't mitigate this fact. A fix should have been given top priority, IMHO.

 

I agree, a patch should have gone out as soon as one was created.

This is how I managed a work around. I found the problem prefabs by trial and error. Find a level that doesn't work and remove calls to Resources.Load until it does work. Then write a script to reintroduce each asset you have just removed to identify each asset that causes the crash. Once you have a list of assets then you need to have these loaded at all times, so have references to them in your main menu. Now replace your calls to Resources.Load with your mainmenu references.

Now you can safely use LoadLevel without triggering the crash.

 

Hello Joachim!

Any updates or progress on this issue? It's hurting our memory usage and build stability quite badly right now.

Cheers,

Brent

 

I am having the same issue and workaround requires a lot of temporary changes.

If we could have an ETA on this, it would be awesome!!

 

Downloading Unity 4.1.3 with fingers crossed...

 

4.1.3 fixes the issue!!!!!!

 

4.1.3 Fixed it for me too.

 

Good!

 

Indeed! Works for me too.

 

Didn't work here.

The win32 executable compiled from the Mac, is crashing upon Application.Quit() or if closing the window.
System.Diagnostic.Process.GetCurrentProcess().Kill is not an option

 

This thread is about a freeze that occurs while running the game on Mac or iOS, when loading a level. You are reporting a crash that occurs on Win32 when closing the game. Ehm... I don't want to sound dismissive, but this looks like a totally different issue to me. Maybe you should start a different thread, providing more information about your specific problem.

 

Pretty sure I saw a thread about Windows builds crashing on quit, and that it's a separate problem (though the symptoms are similar).

Verified that 4.1.3 fixed the issue in this thread for me.

It was really good to see a quality-focused release. Thank you, Unity!

 

"I've found that calling Resources.UnloadUnusedAssets() also triggers a freeze in my project on Mac, same basic symptoms."

This is exactly what I'm getting when I hit play within the Unity Editor. Removing the Resources.Unload fixes it. I'm using 4.1.5f1.

 

I have same issue with 4.1.5f1 in Unity editor on OSX with iOs target selected.

 

I suspect that this issue isn't fully resolved. We have issues with loading levels since 4.1. Please see this thread as well:
http://forum.unity3d.com/threads/188596-Editor-crash-when-hitting-stop-after-load

 

Hi. Has this issue been resolved?

I still get freezes with 4.5 and the OSX Player after some time when using LevelLoad(0) to reload the test/only scene. However, since I am new (2 days) to Unity and doing this from an Update() of a game object, I don't know if this is alowed or calls for trouble (stack-wise).

 

I still get freezes with 2017.3 after loadscene.
there is the stack tracefull trace in files.)
Sampling process 80822 for 1 second with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling Unity (pid 80822) every 1 millisecond
Process: Unity [80822]
Path: /Applications/Unity2017/Unity.app/Contents/MacOS/Unity
Load Address: 0x100000000
Identifier: com.unity3d.UnityEditor5.x
Version: Unity version 2017.3.0f3 (2017.3.0f3)
Code Type: X86-64
Parent Process: ??? [1]
Date/Time: 2018-11-06 10:20:30.219 +0800
Launch Time: 2018-11-06 10:17:49.206 +0800
OS Version: Mac OS X 10.13.6 (17G65)
Report Version: 7
Analysis Tool: /usr/bin/sample
Physical footprint: 630.9M
Physical footprint (peak): 652.6M
----
Call graph:
682 Thread_4071289 DispatchQueue_1: com.apple.main-thread (serial)
+ 682 start (in libdyld.dylib) + 1 [0x7fff7a0cb015]
+ 682 main (in Unity) + 9 [0x1006d2c89]
+ 682 EditorMain(int, char const**) (in Unity) + 839 [0x1006d2807]
+ 682 NSApplicationMain (in AppKit) + 804 [0x7fff4f7d5a72]
+ 682 -[NSApplication run] (in AppKit) + 764 [0x7fff4f806885]
+ 682 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (in AppKit) + 3044 [0x7fff4ffa7e34]
+ 682 _DPSNextEvent (in AppKit) + 2085 [0x7fff4f811a73]
+ 682 _BlockUntilNextEventMatchingListInModeWithFilter (in HIToolbox) + 64 [0x7fff51560884]
+ 682 ReceiveNextEventCommon (in HIToolbox) + 613 [0x7fff51560b06]
+ 682 RunCurrentEventLoopInMode (in HIToolbox) + 286 [0x7fff51560d96]
+ 682 CFRunLoopRunSpecific (in CoreFoundation) + 483 [0x7fff52276153]
+ 682 __CFRunLoopRun (in CoreFoundation) + 2427 [0x7fff52276d5b]
+ 682 __CFRunLoopDoTimers (in CoreFoundation) + 346 [0x7fff5227f78a]
+ 682 __CFRunLoopDoTimer (in CoreFoundation) + 1095 [0x7fff5227fc87]
+ 682 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ (in CoreFoundation) + 20 [0x7fff52280014]
+ 682 __NSFireTimer (in Foundation) + 83 [0x7fff543ea739]
+ 682 Application::TickTimer() (in Unity) + 3828 [0x10199b2d4]
+ 682 PlayerLoopController::UpdateSceneIfNeeded() (in Unity) + 108 [0x10199bfac]
+ 682 PlayerLoopController::UpdateScene(bool) (in Unity) + 1033 [0x1019a08c9]
+ 682 GUIView::RepaintAll(bool) (in Unity) + 949 [0x1006c9775]
+ 682 -[GUIOpenGLView drawRect:] (in Unity) + 346 [0x1006e23ba]
+ 682 -[GUIRenderView renderRect:] (in Unity) + 266 [0x1006e12ea]
+ 682 GUIView:rocessInputEvent(InputEvent&) (in Unity) + 32 [0x10189bf40]
+ 682 GUIView::OnInputEvent(InputEvent&) (in Unity) + 609 [0x1006c7c61]
+ 682 GUIView:rocessRetainedMode(InputEvent&, GUIState&, int) (in Unity) + 84 [0x10189c584]
+ 682 IMGUIScriptingClasses:rocessEvent(int, void*, ScriptingExceptionPtr*) (in Unity) + 236 [0x1005dfb1c]
+ 682 bool ScriptingInvocation::Invoke<bool>(ScriptingExceptionPtr*, bool) (in Unity) + 17 [0x101007ba1]
+ 682 ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool) (in Unity) + 106 [0x101007c9a]
+ 682 mono_runtime_invoke (in libmono.0.dylib) + 117 [0x13d5afab6]
+ 682 ??? (in libmono.0.dylib) load address 0x13d479000 + 0xa1ce [0x13d4831ce]
+ 682 ??? (in <unknown binary>) [0x125701836]
+ 682 ??? (in <unknown binary>) [0x1257016a7]
+ 682 ??? (in <unknown binary>) [0x125701b18]
+ 682 ??? (in <unknown binary>) [0x125701df0]
+ 682 ??? (in <unknown binary>) [0x13fb1bde2]
+ 682 ??? (in <unknown binary>) [0x128c33f0f]
+ 682 ??? (in <unknown binary>) [0x128c378e1]
+ 682 ??? (in <unknown binary>) [0x128c33d16]
+ 682 ??? (in <unknown binary>) [0x128c38cb8]
+ 682 ??? (in <unknown binary>) [0x125843da8]
+ 682 ??? (in <unknown binary>) [0x125844a38]
+ 682 ??? (in <unknown binary>) [0x1258544d1]
+ 682 ??? (in <unknown binary>) [0x12587272b]
+ 682 ??? (in <unknown binary>) [0x1242bd7fa]
+ 682 ??? (in <unknown binary>) [0x1242bd92c]
+ 682 ??? (in <unknown binary>) [0x12116bb76]
+ 682 ??? (in <unknown binary>) [0x121d2152c]
+ 682 ??? (in <unknown binary>) [0x121d21b33]
+ 682 ??? (in libmono.0.dylib) load address 0x13d479000 + 0xfb1e3 [0x13d5741e3]
+ 682 mono_runtime_invoke_array (in libmono.0.dylib) + 946 [0x13d5b585c]
+ 682 mono_runtime_invoke (in libmono.0.dylib) + 117 [0x13d5afab6]
+ 682 ??? (in libmono.0.dylib) load address 0x13d479000 + 0xa1ce [0x13d4831ce]
+ 682 ??? (in <unknown binary>) [0x120efd6aa]
+ 682 ??? (in <unknown binary>) [0x1208cc55e]
+ 682 ??? (in <unknown binary>) [0x1208f8ee7]
+ 682 ??? (in <unknown binary>) [0x1208fbfb2]
+ 682 ??? (in <unknown binary>) [0x120906680]
+ 682 ??? (in <unknown binary>) [0x120906e8a]
+ 682 ??? (in <unknown binary>) [0x120908ce5]
+ 682 ??? (in <unknown binary>) [0x120909b0e]
+ 682 ??? (in <unknown binary>) [0x1209743c2]
+ 682 EditorUtility_CUSTOM_InstanceIDToObject(int) (in Unity) + 61 [0x10255a40d]
+ 682 PPtr<Object>:perator Object*() const (in Unity) + 246 [0x1006aff96]
+ 682 PersistentManager::ReadObject(int, AwakeFromLoadMode) (in Unity) + 210 [0x101091022]
+ 682 PersistentManager::IntegrateObjectAndUnlockIntegrationMutexInternal(int) (in Unity) + 272 [0x101092e50]
+ 682 AwakeFromLoadQueue:ersistentManagerAwakeSingleObject(Object&, AwakeFromLoadMode) (in Unity) + 196 [0x1010849e4]
+ 682 MonoBehaviour::CheckConsistency() (in Unity) + 91 [0x100fbb4cb]
+ 682 PPtr<MonoScript>:perator MonoScript*() const (in Unity) + 262 [0x100c256a6]
+ 682 PersistentManager::ReadObject(int, AwakeFromLoadMode) (in Unity) + 265 [0x101091059]
+ 682 ProfilerMutexAutoLock:rofilerMutexAutoLock(Mutex&, char const*, profiling::Marker&, char const*, int) (in Unity) + 62 [0x101098ade]
+ 682 _pthread_mutex_lock_slow (in libsystem_pthread.dylib) + 253 [0x7fff7a3e14c8]
+ 682 _pthread_mutex_lock_wait (in libsystem_pthread.dylib) + 83 [0x7fff7a3e3b9d]
+ 682 __psynch_mutexwait (in libsystem_kernel.dylib) + 10 [0x7fff7a21ba46]