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)
start + 40 (in Zigfrak) [0x2108c]
_start + 208 (in Zigfrak) [0x2115d]
PlayerMain(int, char const**) + 610 (in Zigfrak) [0xa4b322]
NSApplicationMain + 574 (in AppKit) [0x98488289]
-[NSApplication run] + 821 (in AppKit) [0x984901f3]
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156 (in AppKit) [0x984cddd6]
_DPSNextEvent + 847 (in AppKit) [0x984ce595]
BlockUntilNextEventMatchingListInMode + 81 (in HIToolbox) [0x98f3ca3e]
ReceiveNextEventCommon + 354 (in HIToolbox) [0x98f3cbb9]
RunCurrentEventLoopInMode + 392 (in HIToolbox) [0x98f3ce04]
CFRunLoopRunInMode + 97 (in CoreFoundation) [0x950d91f1]
CFRunLoopRunSpecific + 452 (in CoreFoundation) [0x950d93c4]
__CFRunLoopRun + 8059 (in CoreFoundation) [0x950dba3b]
__NSFireTimer + 141 (in Foundation) [0x93028484]
-[PlayerAppDelegate UpdatePlayer] + 224 (in Zigfrak) [0xa4bc70]
PlayerLoop(bool, bool, IHookEvent*) + 331 (in Zigfrak) [0x7a4aab]
PreloadManager::WaitForAllAsyncOperationsToComplete() + 111 (in Zigfrak) [0x7a89bf]
PreloadManager::UpdatePreloadingSingleStep(bool) + 232 (in Zigfrak) [0x7a7b58]
PreloadLevelOperation::IntegrateMainThread() + 525 (in Zigfrak) [0x7a990d]
PlayerLoadLevelFromThread(int, std::string const, AwakeFromLoadQueue) + 39 (in Zigfrak) [0x7a2857]
LevelLoading::LoadLevel(int, std::string const, AwakeFromLoadQueue) + 1448 (in Zigfrak) [0x7a24b8]
CleanupAfterLoad() + 18 (in Zigfrak) [0x7cfed2]
GarbageCollectSharedAssets(bool) + 889 (in Zigfrak) [0x79d549]
MarkAllDependencies(GarbageCollectorState) + 2676 (in Zigfrak) [0x79ca74]
ReadObjectFromPersistentManager(int) + 38 (in Zigfrak) [0x499ed6]
PersistentManager::ReadObject(int) + 394 (in Zigfrak) [0x86f47a]
AwakeFromLoadQueue::PersistentManagerAwakeSingleObject(Object, TypeTree*, AwakeFromLoadMode, bool, void (*)(Object, TypeTree const)) + 46 (in Zigfrak) [0x86578e]
Unity::GameObject::AwakeFromLoad(AwakeFromLoadMode) + 26 (in Zigfrak) [0x4a8fba]
Unity::GameObject::SetSupportedMessagesDirty() + 44 (in Zigfrak) [0x4a780c]
Unity::GameObject::GetSupportedMessagesRecalculate() + 235 (in Zigfrak) [0x4a76bb]
ReadObjectFromPersistentManager(int) + 38 (in Zigfrak) [0x499ed6]
PersistentManager::ReadObject(int) + 326 (in Zigfrak) [0x86f436]
SerializedFile::ReadObject(long, int, ObjectCreationMode, bool, TypeTree**, bool*, Object**) + 892 (in Zigfrak) [0x876dec]
MonoBehaviour::VirtualRedirectTransfer(StreamedBinaryRead<false>) + 51 (in Zigfrak) [0x7d8993]
void MonoBehaviour::TransferEngineAndInstance<StreamedBinaryRead<false> >(StreamedBinaryRead<false>) + 226 (in Zigfrak) [0x7f95d2]
MonoBehaviour::SetScript(PPtr<MonoScript> const, MonoObject*) + 52 (in Zigfrak) [0x7fe774]
MonoBehaviour::RebuildMonoInstance(MonoObject*) + 408 (in Zigfrak) [0x7fe2d8]
scripting_object_new(MonoClass*) + 26 (in Zigfrak) [0x817b1a]
mono_object_new_specific + 290 (in libmono.0.dylib) [0x1517718]
mono_object_new_alloc_specific + 93 (in libmono.0.dylib) [0x15175bd]
GC_malloc + 79 (in libmono.0.dylib) [0x159b4ed]
GC_lock + 27 (in libmono.0.dylib) [0x15a052e]
semaphore_wait_signal_trap + 10 (in libSystem.B.dylib) [0x96500b42]
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.
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.
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.
0 0x35c550fc in __psynch_mutexwait ()
1 0x3402c128 in pthread_mutex_lock ()
2 0x0152114c in GC_generic_lock ()
3 0x015211a4 in GC_lock ()
4 0x0151bb14 in GC_gcj_malloc ()
5 0x014b6abc in mono_object_new_alloc_specific ()
6 0x014b6c64 in mono_object_new_specific ()
7 0x014baf08 in mono_object_new ()
8 0x014caaec in mono_type_get_object ()
9 0x014b9c18 in mono_class_vtable_full ()
10 0x014baefc in mono_object_new ()
11 0x011130d8 in scripting_object_new(MonoClass*) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Scripting/Backend/Mono/ScriptingBackendApi_Mono.cpp:119
12 0x01109404 in MonoBehaviour::RebuildMonoInstance(MonoObject*) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Mono/MonoBehaviour.cpp:1546
13 0x011095b8 in MonoBehaviour::SetScript(PPtr<MonoScript> const, MonoObject*) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Mono/MonoBehaviour.cpp:1597
14 0x010f7edc in void MonoBehaviour::TransferEngineAndInstance<StreamedBinaryRead<false> >(StreamedBinaryRead<false>) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Mono/MonoBehaviourSerialization.cpp:734
15 0x010f771c in MonoBehaviour::VirtualRedirectTransfer(StreamedBinaryRead<false>) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Mono/MonoBehaviourSerialization.cpp:795
16 0x01144138 in SerializedFile::ReadObject(long, int, ObjectCreationMode, bool, TypeTree**, bool*, Object**) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Serialize/SerializedFile.cpp:1319
17 0x0113ea1c in PersistentManager::ReadObject(int) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Serialize/PersistentManager.cpp:1103
18 0x00f811c0 in ReadObjectFromPersistentManager(int) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/BaseObject.cpp:225
19 0x01054200 in PPtr<Unity::Component>::operator Unity::Component*() const at /Applications/buildAgent/work/7535de4ca26c26ac/./Runtime/BaseClasses/BaseObject.h:849
20 0x00f86dc4 in ImmediatePtr<Unity::Component>::Load() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/BaseObject.h:157
21 0x00f86db4 in ImmediatePtr<Unity::Component>::GetPtr() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/GameObject.cpp:173
22 0x00f86da8 in ImmediatePtr<Unity::Component>::operator Unity::Component*() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/GameObject.cpp:216
23 0x00f86da8 in Unity::GameObject::GetSupportedMessagesRecalculate() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/GameObject.cpp:354
24 0x00f86498 in Unity::GameObject::SetSupportedMessagesDirty() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/GameObject.cpp:339
25 0x00f86438 in Unity::GameObject::AwakeFromLoad(AwakeFromLoadMode) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/GameObject.cpp:103
26 0x0113b034 in AwakeFromLoadQueue::PersistentManagerAwakeSingleObject(Object, TypeTree*, AwakeFromLoadMode, bool, void (*)(Object, TypeTree const)) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Serialize/AwakeFromLoadQueue.cpp:314
27 0x0113ea48 in PersistentManager::ReadObject(int) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Serialize/PersistentManager.cpp:1109
28 0x00f811c0 in ReadObjectFromPersistentManager(int) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/BaseClasses/BaseObject.cpp:225
29 0x012007c4 in PPtr<Unity::GameObject>::operator Unity::GameObject*() const at /Applications/buildAgent/work/7535de4ca26c26ac/./Runtime/BaseClasses/BaseObject.h:849
30 0x011fb9e4 in ImmediatePtr<Unity::GameObject>::Load() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/./Runtime/BaseClasses/BaseObject.h:157
31 0x011fb9d4 in ImmediatePtr<Unity::GameObject>::GetPtr() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/iPhonePlayer-armv7/Graphics.cpp:173
32 0x011fb9c8 in ImmediatePtr<Unity::GameObject>::operator*() const [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/iPhonePlayer-armv7/Graphics.cpp:218
33 0x011fb9c8 in Unity::Component::GetGameObject() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/iPhonePlayer-armv7/Graphics.cpp:327
34 0x010dd59c in ProcessValidComponent [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/GarbageCollectSharedAssets.cpp:716
35 0x010dd594 in ProcessTransform [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/GarbageCollectSharedAssets.cpp:723
36 0x010dd594 in MarkAllDependencies [inlined] at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/GarbageCollectSharedAssets.cpp:895
37 0x010dd474 in GarbageCollectSharedAssets(bool) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/GarbageCollectSharedAssets.cpp:208
38 0x010f3990 in CleanupAfterLoad() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/SaveAndLoadHelper.cpp:757
39 0x010f3f9c in CompletePreloadManagerLoadLevel(std::string const, AwakeFromLoadQueue) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/SaveAndLoadHelper.cpp:938
40 0x010e0c58 in LevelLoading::LoadLevel(int, std::string const, AwakeFromLoadQueue) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/Player.cpp:1214
41 0x010e0a6c in PlayerLoadLevelFromThread(int, std::string const, AwakeFromLoadQueue) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/Player.cpp:337
42 0x010e411c in PreloadLevelOperation::IntegrateMainThread() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/PreloadManager.cpp:761
43 0x010e3444 in PreloadManager::UpdatePreloadingSingleStep(bool) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/PreloadManager.cpp:451
44 0x010e3930 in PreloadManager::WaitForAllAsyncOperationsToComplete() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/PreloadManager.cpp:515
45 0x010e3a38 in PreloadManager::UpdatePreloading() at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/PreloadManager.cpp:538
46 0x010e1b84 in PlayerLoop(bool, bool, IHookEvent*) at /Applications/buildAgent/work/7535de4ca26c26ac/Runtime/Misc/Player.cpp:1579
47 0x00ea9d30 in UnityPlayerLoop() at /Applications/buildAgent/work/7535de4ca26c26ac/PlatformDependent/iPhonePlayer/LibEntryPoint.mm:376
48 0x00005060 in -[AppController Repaint] at /Users/justin/Projects/Unity/Current/Constructed/Builds/ios/ios/Classes/AppController.mm:342
49 0x00004fc0 in -[AppController RepaintDisplayLink] at /Users/justin/Projects/Unity/Current/Constructed/Builds/ios/ios/Classes/AppController.mm:323
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.
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
Then, in every script that used to call Application.LoadLevel() I replace it with a call to LoadLevelWorkaround(sceneName):
// Workaround function to avoid the Unity 4.1 bug that plagues Application.LoadLevel.
// This is done by manually removing all the old objects (unless they are set to Persist) and then loading the specified scene additively
function LoadLevelWorkaround(level : String)
{
// Find all the game objects in the scene
var allTransforms : Transform[] = FindObjectsOfType(Transform);
// Cycle through them and delete everything that isn't set to Persist
for(var i : int = 0; i < allTransforms.length; i++)
{
// Only look at the transform roots
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)
{
var root : Transform = allTransforms[i].root;
if(!root.GetComponent("Persist")) // The object is not set to Persist
{
Destroy(root.gameObject);
}
}
}
// Additively load the specified level
Application.LoadLevelAdditive(level);
}
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
