Unity 4.3 Crashes when Destroying Terrain

I have an asset on the asset store that dynamically loads terrain or other game objects. Everything worked great on 4.2, however, after updating to 4.3, the Unity Editor and Windows Standalone Builds crash when a Terrain is destroyed.

If I use a regular GameObject with no Terrain Component (such as a plane), my dynamic loading program has no trouble destroying the objects, so I know it's something to do with Terrains.

Here is the relevant code where the crash occurs. Note, this code is in a component and is called by another component, and both components are found in a .dll:

Code (csharp):

1. public sealed override void ProcessDeactivatedCellObjects(List<GameObject> deactivatedCellObjects,
2.                                                                          List<ICellLoadData> cellsAssociatedWithObjects)
3. {
4.     for(int i = 0; i < cellsAssociatedWithObjects.Count; i++)
5.     {
6.         Debug.Log("Destroy object " + i);
7.         Destroy(deactivatedCellObjects[i]);
8.         Debug.Log("Object " + i + " destroyed");
9.         //yield return new WaitForSeconds(timeToYieldForAfterDestroyingCellObject);
10.     }
11.     //yield break;
12. }

The commented yields are there because initially this was a Coroutine, and when I was trying to figure out where the crash was occurring using the Debug.Log calls, the method would print "Object 1 destroyed" then crash, so I suspected the yield was causing an issue. However, after removing the yields and making it a method with return type void (changing how the method was called as well), the program still crashes. The differences is the Debug.Log statements print for every object that is destroyed, making me believe the issue is not with the Destroy method, however the program still crashes.

Also, if I switch out the component with the Destroy method for one that doesn't Destroy the object, there is no crashing, which supports the theory that there is an issue with trying to Destroy terrains.

Confusing matters however, is the fact that I have tried to reproduce this crash and cannot seem to do so. I created code that effectively does the same as the code posted (destroying Terrains), and even put the code in a .dll, but no crashing occurs.

I've submitted a bug report, but I really want to try and fix this myself (if possible) as soon as possible, because I said this is an Asset Store product and crashing is a huge issue.

Thanks for any help!

 

Here's the Stack Trace from a crash on a standalone windows build:

Code (csharp):

1. ========== OUTPUTING STACK TRACE ==================
2.  
3. (0x01459BA2) c:\buildagent\work\d3d49558e4d408f4\runtime\terrain\terraininstance.cpp (207 + 0x3): TerrainInstance::GetTerrainRendererDontCreate + 0x12
4. (0x012346AE) c:\buildagent\work\d3d49558e4d408f4\runtime\camera\camera.cpp (965 + 0x0): Camera::CustomCull + 0xae
5. (0x0123490D) c:\buildagent\work\d3d49558e4d408f4\runtime\camera\camera.cpp (801 + 0x0): Camera::Cull + 0x3d
6. (0x0124F687) c:\buildagent\work\d3d49558e4d408f4\runtime\camera\rendermanager.cpp (89 + 0x0): RenderManager::RenderCameras + 0xf7
7. (0x0138C7D4) c:\buildagent\work\d3d49558e4d408f4\runtime\misc\player.cpp (1565 + 0x0): PlayerRender + 0x24
8. (0x0138D476) c:\buildagent\work\d3d49558e4d408f4\runtime\misc\player.cpp (2021 + 0x7): PlayerLoop + 0x6c6
9. (0x013FB2FF) c:\buildagent\work\d3d49558e4d408f4\platformdependent\winplayer\winmain.cpp (483 + 0xea): MainMessageLoop + 0x19f
10. (0x013FCFB9) c:\buildagent\work\d3d49558e4d408f4\platformdependent\winplayer\winmain.cpp (894 + 0x0): PlayerWinMain + 0x859
11. (0x016867D8) c:\buildagent\work\d3d49558e4d408f4\platformdependent\winplayer\shimmain.cpp (6 + 0x15): WinMain + 0x18
12. (0x016B88C0) f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c (275 + 0x1c): __tmainCRTStartup + 0x11a
13. (0x75AA336A) (kernel32): (filename not available): BaseThreadInitThunk + 0x12
14. (0x77189F72) (ntdll): (filename not available): RtlInitializeExceptionChain + 0x63
15. (0x77189F45) (ntdll): (filename not available): RtlInitializeExceptionChain + 0x36
16.  
17. ========== END OF STACKTRACE ===========

As expected, it looks like it has something to do with Terrains.

 

Well, after further testing I don't believe it's the terrain destruction, at least not directly. As far as I can tell, there seems to be an issue with yielding from within a loop where a GameObject is destroyed. Take this code, which produces a crash:

Code (csharp):

1.  
2. IEnumerator DeactivateCellObjects(ActiveGridCell[] cells)
3. {
4.     for(int i = subControllers.Length - 1; i >= 0 ; i--)
5.     {
6.         for(int j = 0; j < cells.Length; j++)
7.         {
8.             if(cells[j].CellObjects[i] != null)
9.             {
10.                 GameObject cellObject = cells[j].CellObjects[i].gameObject;
11.                 cells[j].CellObjects[i] = null;
12.                 gameObjectStateSwitcher.DeactivateGameObject(cellObject);
13.                 cellsAssociatedWithObjects.Add(cells[j]);
14.                 deactivatedCellObjects.Add(cellObject);
15.             }
16.         }
17.         subControllers[i].ProcessDeactivatedCellObjects(deactivatedCellObjects, cellsAssociatedWithObjects);cellsAssociatedWithObjects));
18.  
19.         Debug.Log ("Crash Chance 1");
20.         yield return null;
21.         Debug.Log ("Crash Chance 1 passed");
22.         cellsAssociatedWithObjects.Clear();
23.         deactivatedCellObjects.Clear();
24.     }
25.  
26.     cellsAssociatedWithObjects.Clear();
27.     deactivatedCellObjects.Clear();
28. }
29.  

As I said, this code crashes, however, if I move the yield return null statement to outside the i for loop, it doesn't crash.

Additional Details: subControllers is an array of classes that implement a specific interface. Those classes actually destroy each game object. Each cell contains an array of GameObjects associated with it, in the same order as the sub Controllers (so a GameObject at index 0 in the CellObjects array is associated with the sub controller at index 0 in the subControllers array). The GameObject state switcher disables a GameObject (beside the point). Finally, the variables cellsAssociatedWithObjects and deactivatedCellObjects are instance Lists (used to avoid garbage collection allocation), which is why they are Cleared (so they can be reused).

I already tried taking the lists out of the equation by removing them and passing single objects to the sub controllers for them to destroy, but it didn't solve the issue. I am guessing there is some kind of problem with trying to destroy the game objects in a for loop within an iterator block. As I said, this exact code worked fine in Unity 4.2, so I don't know what has changed.

I am going to keep trying to figure it out, but I could really use some help. Anyone have any ideas? Thanks!

 

So this issue is only effecting me? No one else is having this problem?

 

Hello Gilley
Nope : you r not alone !
I have same issue with similar stack traces
My case : loading (LoadLevelAdditive) and unloading (Destroy) scenes with 1 gameObject + 1 terrain attached + scrolling of the whole thing (from origin to final position based on a collider schema)
Haven't much time to dig the problem though (i am on something else right now and i rolled back to 4.2 waiting for better days)
I am on free version by the way.
I keep an eye on this thread

 

Well, that is comforting to know I am not the only one. I don't really understand the parameters of what is causing the crash. I have basically reproduced my code in a test project (destroying terrain in a coroutine within a for loop, using list, etc.) but the crash does not occur.

Any way you could post a sample of the code where the terrain destruction occurs? Perhaps we can recognize a pattern and figure this thing out. If others are having this issue too, please post your code as well! Thanks!

 

The numbers for the two bug reports concerning this issue are 575662 and 575836.

 

I finally figured out what was going on. Unity must have changed something relating to the Terrain.SetNeighbors function. For whatever reason, Unity was not liking the fact that I was destroying Terrain that had not been properly "de-neighbored". Nulling out the neighbors and calling Terrain.Flush() fixed the issue. I also re-neighbored the other terrains so they no longer referenced the terrain that was about to be destroyed, but I'm not sure if that made any difference.

In any event, problem solved!

Anyone else experiencing crashes relating to Terrains, look to your SetNeighbors code!

 

Hi Gilley
Wow tricky one indeed !
I reinstall 4.3 right away and give a try !

<EDIT>

Confirmed : Reseting all neighbors before destroying have resolved the problem

Big thx for your action and feedback Gilley ^^

 

Glad my work helped you out too. I'm sure there are others out there with the same issue, so hopefully this can help them too.

 

Oh thank god for you!! I've been agonizing for days trying to figure out what was causing this!! I'm going to try your solution right now, I'll edit and let you know if it work!

EDIT:

I can confirm that this fixed my problem; with one caveat: changing the one terrain neighbours to null didn't fix the issue, you have to set all neighbouring terrains accordingly, setting the original terrain to null in the neighbouring ones.

 

THANK YOU both so much. Confirmed both gilley033 and reklass. Had to terrain.SetNeighbors(null, null, null, null), then terrain.Flush(), then also null it on its neighbors, before GameObject.Destroy() it. Otherwise, the Unity editor was crashing completely as soon as I looked at where the old terrain had been.

What a horribly hard to find bug. How did you even guess, gilley033? I might never have figured that out.

 

Thanks for saving me some time debugging this. I too had the exact same problem.

Thanks again

 

Luckily my asset on the asset store works with both Terrains and non Terrains, and in my test the non terrains were not producing the bug. From there, it was just a matter of disabling certain terrain related code until I found what the issue was. I'm glad it helped you all!

 

Many thanks! I've had the same issue.

 

Thank you for posting this solution. Luckily I did not have to waste much time with this problem thanks to a quick google search.