Unity Editor 4.2 crashes silently on play or start

Question

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 t$$anonymous$$s 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 (t$$anonymous$$s 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 t$$anonymous$$s problem, but there are at least half a dozen editor scripts at work and my scene contains literally thousands of gameobjects, all of w$$anonymous$$ch 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 not$$anonymous$$ng to go on.

So I'll start generally... Does anyone know of any reason that Unity would fail in t$$anonymous$$s way? Perhaps someone has experienced somet$$anonymous$$ng 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 somet$$anonymous$$ng more concrete but I am totally stumped with t$$anonymous$$s at the moment. Let me know if there's any specific info I can provide to crack t$$anonymous$$s can of worms open a little bit further...

Answer 1

T$$anonymous$$s problem was tough to resolve and all I have is theory to go on here. I hope that t$$anonymous$$s 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 t$$anonymous$$nk) 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 t$$anonymous$$s, it has to unpack all of the serialized objects at the stored fileIDs and put them into memory.

Now, I don't know about t$$anonymous$$s next part at all -- it is my best guess -- but I t$$anonymous$$nk 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 t$$anonymous$$ngs yet. I t$$anonymous$$nk 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 t$$anonymous$$s 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 c$$anonymous$$ld playing with fire in t$$anonymous$$s case, and you need to take away those script references before it hurts itself.

Hope it helps someone. Seems like a pretty obscure problem.

Answer 2

Answer by DarkPixel · Oct 02, 2013 at 11:54 PM

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.

Add comment · Share

Unity Editor 4.2 crashes silently on play or start

2 Replies

Your answer

Welcome to Unity Answers

Follow this Question

Related Questions