koobas.hobune.stream
Unity Editor 4.2 crashes silently on play or start
I'm currently working on a hex-based map editor for a game and -- big win for me -- I finally have the ability to load in heightmaps and contour the terrain in roughly the style I'm aiming for.
However, now that contouring of the mesh vertices and normals is working, the editor will crash if I ever try to load or play a scene that has been contoured. When this happens, Editor.log provides me the following unhelpful output:
Platform assembly: C:\Program Files (x86)\Unity\Editor\Data\Mono\lib\mono\2.0\System.Xml.Linq.dll (this message is harmless)
Mono: successfully reloaded assembly
-Completed reload, in 1.660 seconds
Failed to postprocess stacktrace StackOverflowException
(Filename: Line: -1)
Failed to postprocess stacktrace StackOverflowException
(Filename: Line: -1)
Failed to postprocess stacktrace StackOverflowException
(Filename: Line: -1)
Failed to postprocess stacktrace StackOverflowException
... and so on and so forth until it dies and crashes out. Unity provides me with no error messages at the time of the crash. The log is all I have to go by.
I would provide a code sample to assist in debugging this problem, but there are at least half a dozen editor scripts at work and my scene contains literally thousands of gameobjects, all of which with their own updates and dynamic mesh scripts. More importantly, I really have no idea what code is causing the problem since I've got nothing to go on.
So I'll start generally... Does anyone know of any reason that Unity would fail in this way? Perhaps someone has experienced something similar and can suggest a workaround? I heard in some other thread that instantiating a ton of gameobjects at once can be trouble, but my map generation script has no trouble hammering out tens of thousands of gameobjects to operate on, so I doubt that's the problem.
I'm truly sorry to not be able to provide something more concrete but I am totally stumped with this at the moment. Let me know if there's any specific info I can provide to crack this can of worms open a little bit further...
This problem was tough to resolve and all I have is theory to go on here. I hope that this helps to resolve similar issues for others.
Unity was storing inspector variables and therefore any references between scripts I had set up in the scene. However, since memory references are non-serializable, Unity (I think) serializes each object pointed to and saves them to disk as a file that it can find in the library at some "fileID" that is kept in the scene file.
When the scene loads, the scene loader needs to instantiate each gameobject in the scene from the data in the scene file and initialize them to the stored parameters. In order to do this, it has to unpack all of the serialized objects at the stored fileIDs and put them into memory.
Now, I don't know about this next part at all -- it is my best guess -- but I think that the scene loader was loading up each serialized script for each gameobject and had not resolved that many of them were pointing to the same things yet. I think the process of loading the scene content is some kind of recursive process and until some kind of check happens to cull the deserialized objects loaded from files that are determined to be duplicates, Unity is using a great deal more memory than it normally needs for the scene.
And thus I blew the stack with recursion that actually has a bound condition for the first time ever.
TO THOSE WHO NEED A QUICK FIX
The best short-term solution I could manage was to get rid of the references I was making between scripts -- at least as inspector variables. You are free to store these references in private members and recompute them each time your scene Start()s in the editor, or even to store this data in a file of your own to load them in if you want to. I didn't, but I can't see a reason you couldn't do that. However, Unity's scene loader routine is a child playing with fire in this case, and you need to take away those script references before it hurts itself.
Hope it helps someone. Seems like a pretty obscure problem.
Stackoverflow means you have a function that call ifself without a stopping condition. Check for any recursive function. Try commenting them and reload the scene until the crash stopped, you will probably find the problematic function that way.
