GC gives a fatal error

Hi there,

I've encountered a crash (or freeze depending on your point of view) where unity throws a fatal error:
"GC Fatal Error"
"too many root set"

Then unity just freezes and doesn't quit (with maxed out CPU usage). Have to end the process manually.

It's the first time unity does that to me and I'm hoping it's not related to my code/project too much.. so what I'm asking is if anyone else got that error and if I should be searching for a problem or is it editor endemic and bad resource management ? (My project is quite big)

Relevant info:
Win Xp
4gb RAM
Unity 3.2 Pro

Thanks.

 

I have the same error.

Win 7
4gb RAM
Unity 3.2 Pro.

 

prèsque the same me too.

 

did you have it before in 3.1?

 

otherwise post a bug right now.

 

I got this error once (can't remember if it was 3.1 or 3.2). I'm not sure what the circumstances were though.

 

same here...
happened the third time now. always between pressing play and the actual game start.

win7 64bit
unity 3.2 pro

 

got similar one about gc but about thread and my issue i think was because i was using an insane number of coroutine in parallele, so i i change the doing that and no more error

not sure for everybody else

anyway i dont remember got this doing same on 3.1

 

"GC Fatal Error"
"too many root set"

I've had this error 4/5 times since upgrading to 3.2.

Windows 7, 64 bit, Unity Pro.

 

I can actually reproduce this pretty consistently. I'm working on a project where I'm tweaking inputs and starting and stopping the editor embedded player repeatedly. After a number of cycles this error will be thrown consistently.

Restart Unity and it's good for a number of runs after that, then it repeats.

Win7 x64

 

I don't know if it happens repetitively after the first instance because when I get this error Unity Editor stops responding. I've tried waiting several minutes but it never recovers. I have to bring up the task manager and kill the Unity Editor task, loosing all unsaved work in the process. I save often, but even 10/15 mins of doing the same stuff over again is rather annoying.

Thankfully this doesn't seem to happen too often. I've only encountered it about once a week.

 

Yeah, I was not clear on that; Unity is locked for me as well. It's after I kill it and restart that I can repeat the error.

 

Same here : Fatal error in gc - Too many root sets.

Happens fequently when I have worked a long time ( about 3 hours ) in a project with extensive testing.
Looks like some buffer slowly fills up and gives me this message .

Only solution is to reset app and hoping you have saved the scene.

On win Unity 3.2 pro.

 

I have the same error, and found this thread via Google.

Mine comes about while working with System.Net.Sockets asynchronous calls. And only after a socket connection is established. What I've found, though, is that the error only shows up when running from within the Unity Editor. A build of the same project works fine. When the error message box shows up, I click OK, and Unity freezes. Task Manager shows the CPU usage as pegged for Unity.exe. I then have to "End Process." One of our other developers is seeing the same behavior on his machine, so it isn't just me.

The code I'm working with was developed on Unity 3.1 Pro, and worked just fine when run from the Editor. So, all fingers point at some change in 3.2's garbage collection handling while running from the Editor. I need to reuse this code for a new project, so I may have to revert to 3.1 to keep a steady workflow.

Has anyone submitted this as a bug yet? Since the Unity bug tracker isn't public, and therefore not searchable, we are left to rely on the forums for avoiding bug submission floods.

Unity 3.2 Pro
Windows XP SP3

 

Vote for it -

http://feedback.unity3d.com/forums/...64705-public-searchable-bug-tracker?ref=title

Still, bug submission floods are likely what they want. The more reports the more likely it'll get fixed.

Also, for things like this you should be looking it up in Mono's bug tracker.

 

Unity saves scene to [projectdir]/Temp/_EditModeScene every time you press play. Yes, it makes no attempt to recover or even tell you about the file, and you can still lose unsaved Project changes. File is deleted as soon as you rerun Unity.

As to the error, I've had it even when not playing, just switching from MonoDevelop back to Unity.

 

I wouldn't figure it to be a Mono bug, though, as it only happens (in my case, at least) while running from the Unity Editor. Once the project is built as a standalone executable, it works as expected. Makes me think that it is a problem with the Unity Editor. Unless it has to do with some kind of Release vs. Debug thing that I don't know about.

And I voted for the public tracker.

 

Just updated to v3.3 hoping there would be some unmentioned fix for my situation in there somewhere. The problem persisted, though. Reverted to v3.1 and all is well again. Oh well.

 

Same problem here. I alt+tab alot between visual and Unity, and it always happens when I alt+tab back to Unity. Alt-tab triggers it for me, I do not even get start the game simulation.

Windows 7 64 bit, no service pack as of yet.
i7 860 @ 2.80Ghz. 8 GB RAM. ATI Radeon HD 5700.

 

I also get the error in 3.3... in the same circumstances, at about the same frequency, sometimes without the popup. :-(

Is it actually possible to go back to 3.1? Can it read projects from 3.3?

 

it will potentially lose data as 3.2 was a breaking update, but you must not needfully do so, I had no problems for example on a test project

 

I'm having the same error (Win XP, Unity 3.3). I'm using a lot of Coroutines, and I would obviously prefer not to rewrite or down-rev Unity for this.
Is it true that this won't affect builds?

 

As mentioned previously in this thread, submit your own bug report. Don't wait for someone else to do it.

 

I'm getting the same error. Like MOverlund said, it's from starting running the editor player over and over again to make little tweaks.

 

Also getting this - seems to be inline with what others see as the cause.

 

It has to do something with scripts. I have scene, where this happens after few minutes and scenes, where it never happen. I am using 3.2 pro.

 

I get this 2-3 times a week. Really frustrating, cause you loose all work not saved on scene. How about implementing some auto-save-scene thing Unity people? So we can recover work after a crash.

Edit: using v.3.3

 

There is a half-baked "auto save" - the [projectdir]/Temp/_EditModeScene is your scene file at last Run. No auto-save of Project though (eg. Materials).

 

I'm in a similar situation to this (though I can't say whether or not it would've worked in an older Unity version). I just added some System.Threading.Thread code to my project as part of a multithreading experiment and got this error. Basically I send somewhere under 15-20 threads off to do their own calculations, then .Join() them all waiting for them to finish. About 30 seconds into a level that uses this every couple updates, the error occurs. Doing these exact same calculations in sequence instead of multithreading them does not cause the error. In addition, I do not keep any references to the Threads after the .Join()s are all done, so I'm not keeping a dramatically increasing quantity of them in memory over time (though I suppose creating all those threads then disposing of them probably wasn't being kind to the GC).

A build does not cause the error (At least, not in a full playthrough of the level. I didn't test the level multiple times to see if it would occur after the application's been running a bit longer), only the Editor.

 

I just made a quick test script to reproduce this and submitted a bug report with it. Running an empty level with only this script active and UseMultithreading checked causes the crash. (Sorry for the weird naming conventions, I just wanted to whip this up quickly)

I don't think I'm doing anything particularly wrong that would cause this (Other than horribly inefficient use of threading out functions which was only done for the sake of testing), but if I am, I'd love to know what. I haven't done much with multithreading in Unity yet.

Code (csharp):

1. using UnityEngine;
2. //using UnityEditor;
3. using System.Collections.Generic;
4. using System.Threading;
5.  
6. /// <summary>
7. /// This class exists for the purpose of testing out the Garbage Collector fatal error: "Too many root sets".
8. /// I can reproduce this by multithreading out a bunch of little helper functions then .Join()ing their threads.
9. /// This only seems to crash the Unity editor, NOT a build.
10. /// http://forum.unity3d.com/threads/78282-GC-gives-a-fatal-error
11. /// </summary>
12. public class MultithreadingErrorTesting : MonoBehaviour
13. {
14.     /// <summary>
15.     /// If this is checked, Multithreading out the operations will happen.
16.     /// If not, the functions will run in sequence.
17.     /// </summary>
18.     public bool UseMultithreading = true;
19.  
20.     /// <summary>
21.     /// A dictionary for storing the results of the operations being threaded out.
22.     /// </summary>
23.     private Dictionary<BlarghRandomTestClass, bool> _areRandomResultsEven = new Dictionary<BlarghRandomTestClass, bool>();
24.  
25.     /// <summary>
26.     /// A list containing all the created test classes.
27.     /// </summary>
28.     private List<BlarghRandomTestClass> _blarghs = new List<BlarghRandomTestClass>();
29.  
30.     /// <summary>
31.     /// A list containing the threads that have been started.
32.     /// </summary>
33.     private List<Thread> _threads = new List<Thread>();
34.  
35.     /// <summary>
36.     /// How many updates have occurred?
37.     /// </summary>
38.     private long _updateCount = 0;
39.  
40.     /// <summary>
41.     /// This is just a test class for the sake of having something to operate on in the threaded function call.
42.     /// </summary>
43.     private class BlarghRandomTestClass
44.     {
45.         public int Number;
46.         private static System.Random _random;
47.         public static System.Random RandomInstance
48.         {
49.             get
50.             {
51.                 if (_random == null)
52.                 {
53.                     _random = new System.Random();
54.                 }
55.                 return _random;
56.                
57.             }
58.         }
59.         public BlarghRandomTestClass()
60.         {
61.             Number = RandomInstance.Next();
62.         }
63.         public BlarghRandomTestClass(int inNumber)
64.         {
65.             Number = inNumber;
66.         }
67.         public override bool Equals(object obj)
68.         {
69.             if (obj as BlarghRandomTestClass != null)
70.             {
71.                 return ((BlarghRandomTestClass)obj).Number == Number;
72.             }
73.             else return false;
74.         }
75.         public override int GetHashCode()
76.         {
77.             return Number.GetHashCode();
78.         }
79.         public static bool operator ==(BlarghRandomTestClass b1, BlarghRandomTestClass b2)
80.         {
81.             return b1.Equals(b2);
82.         }
83.         public static bool operator !=(BlarghRandomTestClass b1, BlarghRandomTestClass b2)
84.         {
85.             return !b1.Equals(b2);
86.         }
87.     }
88.  
89.  
90.     /// <summary>
91.     /// Set up the test classes we'll be using.
92.     /// </summary>
93.     void Start()
94.     {
95.         for (int count = 0; count < BlarghRandomTestClass.RandomInstance.Next(20, 45); ++count)
96.         {
97.             _blarghs.Add(new BlarghRandomTestClass());
98.         }
99.     }
100.  
101.  
102.     /// <summary>
103.     /// Run the calculations frequently.
104.     /// </summary>
105.     void FixedUpdate()
106.     {
107.         Debug.Log("New update.");
108.  
109.         //Clear out old results.
110.         _areRandomResultsEven.Clear();
111.  
112.         //If we're multithreading:
113.         if (UseMultithreading)
114.         {
115.             foreach (BlarghRandomTestClass blargh in _blarghs)
116.             {
117.                 //Create a thread for doing math with each test class, then start it and add the thread to the list of threads.
118.                 Thread calcThread = new Thread(CheckBlarghSubtractionForEvenness);
119.                 _threads.Add(calcThread);
120.                 calcThread.Start(blargh);
121.             }
122.             foreach (Thread t in _threads)
123.             {
124.                 //Then, wait for every thread to terminate.
125.                 t.Join();
126.                 if (t.IsAlive)
127.                 {
128.                     //It's pretty much a given after a .Join(), but I'm ensuring the thread is dead. I have not seen this error ever printed.
129.                     //According to http://stackoverflow.com/questions/1036403/will-net-garbage-collect-an-object-thats-not-referenced-but-has-a-thread-that
130.                     //Running threads are considered referenced and will not be collected.
131.                     //However, the fact that this is not alive should mean that it is eligible for collection.
132.                     Debug.LogError("Hey, a thread here is still alive!");
133.                 }
134.             }
135.             //Clear out the list of threads so there are no remaining references to them and they can be garbage collected.
136.             _threads.Clear();
137.         }
138.         else
139.         {
140.             //Otherwise, execute the calculations in sequence.
141.             foreach (BlarghRandomTestClass blargh in _blarghs)
142.             {
143.                 CheckBlarghSubtractionForEvenness(blargh);
144.             }
145.         }
146.  
147.         ////Show the results (Unnecessary for the purposes of this test)
148.         //foreach (KeyValuePair<BlarghRandomTestClass, bool> kvp in _areRandomResultsEven)
149.         //{
150.         //    Debug.Log(kvp.Key.Number + ": " + kvp.Value);
151.         //}
152.  
153.         //After <100 updates, the Too Many Root Sets error should freeze up Unity.
154.         Debug.Log("Update is done. " + ++_updateCount);
155.     }
156.  
157.     /// <summary>
158.     /// Meaningless math for the sake of multithreading execution testing.
159.     /// This is the function being multithreaded out.
160.     /// </summary>
161.     /// <param name="inBlargh">The argument to pass to the function.</param>
162.     void CheckBlarghSubtractionForEvenness(object inBlargh)
163.     {
164.         BlarghRandomTestClass blargh = (BlarghRandomTestClass)inBlargh;
165.         if ((blargh.Number - BlarghRandomTestClass.RandomInstance.Next()) % 2 == 0)
166.         {
167.             _areRandomResultsEven.Add(blargh, true);
168.         }
169.         else
170.         {
171.             _areRandomResultsEven.Add(blargh, false);
172.         }
173.     }
174. }

 

I'm starting to worry about this issue. Are there any new developments?

 

This is what I really hate about Unity. Because there is no public bug tracker, you never know, what is state of any bug, if UT know already about it, or if I should spam them with bug report 2x a day, until somebody notices.

 

I get this too, it's getting pretty annoying. I have no idea what causes it for me though, it appears sometimes when I press play in the editor.

 

Click the link in my sig and vote.

 

Done. But I am afraid, that this will have no effect. No public bug tracker is probably decision of some manager or clown from sales, such people think, that hide bugs mean more sells.

 

There appear to be several different situations where this error can occur. One of them is now fixed and another appears to be fixable by changing the DEP settings. The other instances have proved elusive, partly because of their very nature and partly due to a lack of information supplied by people filing the bug reports. If you encounter this message then please file a new bug report. Any extra information could be very useful in tracking the problem down.

 

I got this one, too, with build 3.3.0f4. I lost a bunch of work ;(

I wish unity had an option to auto save scene on play.

 

Got this error for the first time and it pissed me the hell off as I have to reconstruct a section of UI I was working on.

It is really annoying that the scene isn't saved when you push play. As a developer I'm used to my project builds being saved whenever you run the project. So at least if something goes wrong you have the last instance before things broke. Now I have to train myself to constantly save the scene while working. Ugh... >_<

 

Same error
Win 7 x64 SP1, Unity 3.3
occurs several times

 

Case 407364

 

gaaaaah This happens at least 3 times per day

 

It happens every day now. I have to restart Unity pro 3.3 over and over again.

 

Still here for Async sockets ;(

 

This one does indeed happen on regular basis.

 

Is there any solution?
I read that it seems that this bug is caused by restarting the Editor Player too many times. For example, if you were making small tweaks to something and checking how it looked, dozens of times.
Is that true? If I reinstall unity editor will I solve this problem?
Thanks for your help

 

Looks, that bug will never be fixed.

 

They are fixing bugs less and less. They are busy adding support for new and new platforms and bringing only more bugs and instabilities. I can name 10 critical bugs not fixed for 1/2 year, but they are working on flash support.....

 

Same bug here, randomly. Don't know why.

 

Same here, using sockets in project with Unity 3.4f5 It happens 4 + times a day