Stack Overflow Error causing build to fail? (2020.2.0b8 and 2020.2.0b9)

[NotaNaN]

All of my code works fantastic in the editor — but when I try to build my game, I receive a Stack Overflow error, causing the build to fail. This error occurred in 2020.2.0b8, but I hoped upgrading to 2020.2.0b9 was going to magically remedy it. (It did not).

Anybody here speak Stacktrace?

Full Stack Trace

Stack overflow.
0x00007ff6b8bb698c (Unity) StackWalker::GetCurrentCallstack
0x00007ff6b8bbed69 (Unity) StackWalker::ShowCallstack
0x00007ff6ba07541c (Unity) GetStacktrace
0x00007ff6bb114d33 (Unity) DebugStringToFile
0x00007ff6b8c6e789 (Unity) DebugLogHandler_CUSTOM_Internal_Log
0x000001750e7bebfb (Mono JIT Code) (wrapper managed-to-native) UnityEngine.DebugLogHandler:Internal_Log (UnityEngine.LogType,UnityEngine.LogOption,string,UnityEngine.Object)
0x000001750e7beb2b (Mono JIT Code) UnityEngine.DebugLogHandler:LogFormat (UnityEngine.LogType,UnityEngine.Object,string,object[])
0x000001750e7be870 (Mono JIT Code) UnityEngine.Logger:Log (UnityEngine.LogType,object)
0x000001778c911605 (Mono JIT Code) UnityEngine.Debug:LogError (object)
0x000001778c9109d3 (Mono JIT Code) UnityEditor.Build.Player.BuildPlayerDataGeneratorProcess:ProcessExit (UnityEditor.Utils.Program)
0x000001778c9108cb (Mono JIT Code) UnityEditor.Build.Player.BuildPlayerDataGeneratorProcess/<>c__DisplayClass4_0:<Execute>b__0 (object,System.EventArgs)
0x000001778c910657 (Mono JIT Code) System.Diagnostics.Process:OnExited ()
0x000001778c91048b (Mono JIT Code) System.Diagnostics.Process:RaiseOnExited ()
0x000001750671cb6b (Mono JIT Code) System.Diagnostics.Process:WaitForExit (int)
0x000001778c90da4b (Mono JIT Code) (wrapper remoting-invoke-with-check) System.Diagnostics.Process:WaitForExit (int)
0x000001778c90d933 (Mono JIT Code) UnityEditor.Utils.Program:WaitForExit (int)
0x000001778c907473 (Mono JIT Code) UnityEditor.Build.Player.BuildPlayerDataGeneratorProcess:Execute (UnityEditor.Build.Player.BuildPlayerDataGeneratorOptions)
0x000001778c903a2e (Mono JIT Code) UnityEditor.Build.Player.BuildPlayerDataGenerator:GenerateForAssemblies (string[],string[],UnityEditor.BuildTarget,bool)
0x000001778c9033d3 (Mono JIT Code) UnityEditor.Build.Player.BuildPlayerDataGeneratorNativeInterface:GenerateForAssemblies (string[],string[],UnityEditor.BuildTarget,bool)
0x000001778c9034b3 (Mono JIT Code) (wrapper runtime-invoke) <Module>:runtime_invoke_void_object_object_int_byte (object,intptr,intptr,intptr)
0x00007ffd34c7de60 (mono-2.0-bdwgc) [mini-runtime.c:2812] mono_jit_runtime_invoke
0x00007ffd34c02902 (mono-2.0-bdwgc) [object.c:2921] do_runtime_invoke
0x00007ffd34c0b95f (mono-2.0-bdwgc) [object.c:2968] mono_runtime_invoke
0x00007ff6b8a345d4 (Unity) scripting_method_invoke
0x00007ff6b8a2cde5 (Unity) ScriptingInvocation::Invoke
0x00007ff6b8a25f55 (Unity) ScriptingInvocation::Invoke<void>
0x00007ff6b70ac935 (Unity) Scripting::UnityEditor::Build::Player::BuildPlayerDataGeneratorNativeInterfaceProxy::GenerateForAssemblies
0x00007ff6ba379cc0 (Unity) BuildPipeline::GenerateBuildPlayerData
0x00007ff6ba377b45 (Unity) BuildPipeline::GenerateAssemblyTypeInfos
0x00007ff6bb455bd3 (Unity) ProducePlayerScriptAssemblies
0x00007ff6bb444670 (Unity) BuildPlayer
0x00007ff6ba921cbf (Unity) BuildPipeline::BuildPlayerInternalNoCheck
0x00007ff6ba74400a (Unity) BuildPipeline_CUSTOM_BuildPlayerInternalNoCheck
0x00000176ff9fcbca (Mono JIT Code) (wrapper managed-to-native) UnityEditor.BuildPipeline:BuildPlayerInternalNoCheck (string[],string,string,UnityEditor.BuildTargetGroup,UnityEditor.BuildTarget,UnityEditor.BuildOptions,string[],bool)
0x00000176ff9fc513 (Mono JIT Code) UnityEditor.BuildPlayerWindow/DefaultBuildMethods:BuildPlayer (UnityEditor.BuildPlayerOptions)
0x00000176ff9f85db (Mono JIT Code) UnityEditor.BuildPlayerWindow:CallBuildMethods (bool,UnityEditor.BuildOptions)
0x00000176d3a06323 (Mono JIT Code) UnityEditor.BuildPlayerWindow:GUIBuildButtons (UnityEditor.Modules.IBuildWindowExtension,bool,bool,bool,UnityEditor.Build.BuildPlatform)
0x00000176d39fb933 (Mono JIT Code) UnityEditor.BuildPlayerWindow:ShowBuildTargetSettings ()
0x00000176d39eaa43 (Mono JIT Code) UnityEditor.BuildPlayerWindow:OnGUI ()
0x00000176d39a7e83 (Mono JIT Code) UnityEditor.HostView:InvokeOnGUI (UnityEngine.Rect,UnityEngine.Rect)
0x00000176d39a7c33 (Mono JIT Code) UnityEditor.DockArea:smile:rawView (UnityEngine.Rect,UnityEngine.Rect)
0x00000176d399b8d3 (Mono JIT Code) UnityEditor.DockArea:OldOnGUI ()
0x00000176d3982960 (Mono JIT Code) UnityEngine.UIElements.IMGUIContainer:smile:oOnGUI (UnityEngine.Event,UnityEngine.Matrix4x4,UnityEngine.Rect,bool,UnityEngine.Rect,System.Action,bool)
0x00000176d3981aab (Mono JIT Code) UnityEngine.UIElements.IMGUIContainer:HandleIMGUIEvent (UnityEngine.Event,UnityEngine.Matrix4x4,UnityEngine.Rect,System.Action,bool)
0x00000176ff9e8a7b (Mono JIT Code) UnityEngine.UIElements.IMGUIContainer:HandleIMGUIEvent (UnityEngine.Event,System.Action,bool)
0x00000176ff9e8903 (Mono JIT Code) UnityEngine.UIElements.IMGUIContainer:HandleIMGUIEvent (UnityEngine.Event,bool)
0x00000176ff9e821b (Mono JIT Code) UnityEngine.UIElements.IMGUIContainer:SendEventToIMGUIRaw (UnityEngine.UIElements.EventBase,bool,bool)
0x00000176ff9e5833 (Mono JIT Code) UnityEngine.UIElements.IMGUIContainer:SendEventToIMGUI (UnityEngine.UIElements.EventBase,bool,bool)
0x000001750f66b60b (Mono JIT Code) UnityEngine.UIElements.IMGUIContainer:HandleEvent (UnityEngine.UIElements.EventBase)
0x000001750f650718 (Mono JIT Code) UnityEngine.UIElements.CallbackEventHandler:HandleEventAtTargetPhase (UnityEngine.UIElements.EventBase)
0x00000176ff9e2d23 (Mono JIT Code) UnityEngine.UIElements.MouseCaptureDispatchingStrategy:smile:ispatchEvent (UnityEngine.UIElements.EventBase,UnityEngine.UIElements.IPanel)
0x000001750f64e92e (Mono JIT Code) UnityEngine.UIElements.EventDispatcher:ApplyDispatchingStrategies (UnityEngine.UIElements.EventBase,UnityEngine.UIElements.IPanel,bool)
0x000001750f64e423 (Mono JIT Code) UnityEngine.UIElements.EventDispatcher:ProcessEvent (UnityEngine.UIElements.EventBase,UnityEngine.UIElements.IPanel)
0x000001750f653dab (Mono JIT Code) UnityEngine.UIElements.EventDispatcher:ProcessEventQueue ()
0x000001750f652433 (Mono JIT Code) UnityEngine.UIElements.EventDispatcher:OpenGate ()
0x000001750f65237b (Mono JIT Code) UnityEngine.UIElements.EventDispatcherGate:smile:ispose ()
0x000001750f64e6b3 (Mono JIT Code) UnityEngine.UIElements.EventDispatcher:ProcessEvent (UnityEngine.UIElements.EventBase,UnityEngine.UIElements.IPanel)
0x000001750f64ddf3 (Mono JIT Code) UnityEngine.UIElements.EventDispatcher:smile:ispatch (UnityEngine.UIElements.EventBase,UnityEngine.UIElements.IPanel,UnityEngine.UIElements.DispatchMode)
0x000001750f64dc6b (Mono JIT Code) UnityEngine.UIElements.BaseVisualElementPanel:SendEvent (UnityEngine.UIElements.EventBase,UnityEngine.UIElements.DispatchMode)
0x00000176d3945f6b (Mono JIT Code) UnityEngine.UIElements.UIElementsUtility:smile:oDispatch (UnityEngine.UIElements.BaseVisualElementPanel)
0x00000176d3945a4b (Mono JIT Code) UnityEngine.UIElements.UIElementsUtility:UnityEngine.UIElements.IUIElementsUtility.ProcessEvent (int,intptr,bool&)
0x00000176d394584f (Mono JIT Code) UnityEngine.UIElements.UIEventRegistration:ProcessEvent (int,intptr)
0x00000176d394578b (Mono JIT Code) UnityEngine.UIElements.UIEventRegistration/<>c:<.cctor>b__1_2 (int,intptr)
0x00000176d39455ed (Mono JIT Code) UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)
0x00000176d394569e (Mono JIT Code) (wrapper runtime-invoke) <Module>:runtime_invoke_void_int_intptr_intptr& (object,intptr,intptr,intptr)
0x00007ffd34c7de60 (mono-2.0-bdwgc) [mini-runtime.c:2812] mono_jit_runtime_invoke
0x00007ffd34c02902 (mono-2.0-bdwgc) [object.c:2921] do_runtime_invoke
0x00007ffd34c0b95f (mono-2.0-bdwgc) [object.c:2968] mono_runtime_invoke
0x00007ff6b8a345d4 (Unity) scripting_method_invoke
0x00007ff6b8a2cde5 (Unity) ScriptingInvocation::Invoke
0x00007ff6b8a25f55 (Unity) ScriptingInvocation::Invoke<void>
0x00007ff6b70fdaed (Unity) Scripting::UnityEngine::GUIUtilityProxy::ProcessEvent
0x00007ff6b964f086 (Unity) GUIView::ProcessRetainedMode
0x00007ff6ba0b7485 (Unity) GUIView::OnInputEvent
0x00007ff6b964ef78 (Unity) GUIView::ProcessInputEvent
0x00007ff6ba0b894b (Unity) GUIView::ProcessEventMessages
0x00007ff6ba0aff13 (Unity) GUIView::GUIViewWndProc
0x00007ffd8e855c1d (USER32) CallWindowProcW
0x00007ffd8e855612 (USER32) DispatchMessageW
0x00007ff6ba07ea49 (Unity) MainMessageLoop
0x00007ff6ba082af1 (Unity) WinMain
0x00007ff6bbea71f6 (Unity) __scrt_common_main_seh
0x00007ffd8d8e7c24 (KERNEL32) BaseThreadInitThunk
0x00007ffd8ed2cea1 (ntdll) RtlUserThreadStart

EDIT:
Just as a quick note:
My builds do not really “fail” in the sense that the build was unable to complete.
The builds do complete — it’s just an error is thrown part way (Stack Overflow error) and when I run my build-ed application stuff is really broken .

[Baste]

That just looks like the stack trace for Debug.Log. In particular, it looks like the stack trace of somebody pressing the “build” button, and the build process writing something to the console.

Not 100% sure, but it might be that the actual stack overflow is somewhere else? The vast majority of stack overflows are infinite loops involving recursive methods, but they can also happen if you try to obscenely much stuff on the stack for other reasons.

[NotaNaN]

Thanks for the reply!

@Baste

Not 100% sure, but it might be that the actual stack overflow is somewhere else? The vast majority of stack overflows are infinite loops involving recursive methods, but they can also happen if you try to obscenely much stuff on the stack for other reasons.

Yeah, I was worried you might say something along the lines of that.

Every week, I make a build of my project to make sure everything is going smoothly and still runs properly in-build. The issue is that I have made hundreds of edits and added many more files since my last successful build. Trying to debug an error that occurs only on build compilation, of which can only be tested by removing files from a project (and those files are tangled with dependencies, mind you), sounds like the ultimate debugging nightmare.

In my project, I do not have a single recursive method (that I am aware of), and even if I did, shouldn’t it blow up when the method runs, rather than when the code gets compiled — or more oddly, compiled for a build?
I’m not the brightest bulb in the box, which is why I’m asking if this would be the normal behavior (as this is what I always expected).

Also, is there any weird, unmentioned upper limit on how many Component you’re allowed to have on a single GameObject? Currently, I have 31 Components on one GameObject (2 Unity Components and 29 Scripts, I didn’t count the Transform). I’m guessing that isn’t the issue… but I felt like I should ask, as I plan to probably double that number before this is over, and it could become in issue.

Mr. Baste, sir, I do not suppose you have any arcane intuition of what might cause an issue as this (other than a nasty unbridled recursive method), but if you do, what level of “putting an obscene amount of stuff on the stack” is required in order to cause the build to fail on compile? (I’d love to know, because after you answer I’m probably going to backup my project and slowly tear out files until I find the problematic one).

Any and all replies are greatly appreciated!
Thank you for the time you have already spent assisting me troubleshoot.

[Tautvydas-Zilys]

I suggest attaching Visual Studio to Unity.exe before initiating the build. Hopefully that makes it catch the crash and give you the real callstack.

[NotaNaN]

@Tautvydas-Zilys

I suggest attaching Visual Studio to Unity.exe before initiating the build. Hopefully that makes it catch the crash and give you the real callstack.

I will try this as soon as I’m able and I will update the thread with the real stack! Hopefully it’s ridiculously obvious where my problem is once I get it.

Thanks for the recommendation!

[Baste]

@NotaNaN

Mr. Baste, sir, I do not suppose you have any arcane intuition of what might cause an issue as this (other than a nasty unbridled recursive method), but if you do, what level of “putting an obscene amount of stuff on the stack” is required in order to cause the build to fail on compile? (I’d love to know, because after you answer I’m probably going to backup my project and slowly tear out files until I find the problematic one).

Well, since you’re on a beta version of the engine, it might be that you’re triggering an internal bug in the engine - aka. “not your fault”.

It’s most probably not any of your game code causing this - and, no, there’s no limit on the number of MonoBehaviours. If it’s crashing during the build, it’s due to code that’s running during the build - which is either Unity’s stuff like the compilation or scene building, or code you’ve written that happens during build (ie. if you’re using OnPostProcessBuild, [PostProcessScene], stuff like that).

For sure try to attach the debugger to the process.

If that doesn’t tell you anything, a good way to bisect this before you start ripping out files is to check build options. Try just building an empty scene, try building with/without IL2CPP, etc.

Finally, this is why you use source control. If you’d been using git or svn, you could go back to earlier commits and run builds with them in a binary-search fashion, which would allow you to pretty quickly pinpoint which commit was the problem, rather than having to consider all of your changes as a whole.

[NotaNaN]

@Tautvydas-Zilys

I suggest attaching Visual Studio to Unity.exe before initiating the build. Hopefully that makes it catch the crash and give you the real callstack.

I attached Visual Studio to the Unity.exe and attempted to build, the build succeeded, but the Stack Overflow error popped up again.

I noticed that Unity creates two more executables whenever I try to build, so I also connected Visual Studio to “netcorerun.exe” to see if that would give me results. (It did not).

To attach to Unity, I did (while in Visual Studio):
Debug > Attach to Process…
And then navigated to Unity’s .exe and attached to it. (Same process for “netcorerun.exe”)

I also tried:
Debug > Attach Unity Debugger
However the results were the same.

Just as a quick note:
My builds do not really “fail” in the sense that the build was unable to complete.
The builds do complete — it’s just an error is thrown part way (Stack Overflow error) and when I run my build-ed application stuff is really broken .

I feel like I should have mention that sooner.

[NotaNaN]

@Baste

Well, since you’re on a beta version of the engine, it might be that you’re triggering an internal bug in the engine - aka. “not your fault”.

Something tells me it is “my fault” because if I remove all of my scripts from my project the build succeeds without error.
I know. It’s a bad sign.

It’s most probably not any of your game code causing this

Yeah, I figured as much.
Best-case scenario; I move to an older, more stable Unity version and everything just works.

@Baste

there’s no limit on the number of MonoBehaviours.

Yeah, I suspected that to be the case. I just wanted to make sure.
I know there are performance hits to GetComponent when it is performed on larger GameObjects due to it getting Components by iterating over all the Components on a GameObject to find the one it wants, though. So there’s still a small price to pay.

@Baste

If it’s crashing during the build, it’s due to code that’s running during the build - which is either Unity’s stuff like the compilation or scene building, or code you’ve written that happens during build (ie. if you’re using OnPostProcessBuild, [PostProcessScene], stuff like that).

Luckily, I don’t use OnPostProcessBuild or [PostProcessScene], but I do have some Preprocessor Directives in my code. I’ve looked over them and it seems like nothing should be causing an issue — none of them really do anything but remove in-editor warnings for myself so that way they do not run in a build. But I’ll probably look over them again just to make sure I didn’t miss something.

@Baste

If that doesn’t tell you anything, a good way to bisect this before you start ripping out files is to check build options. Try just building an empty scene, try building with/without IL2CPP, etc.

Smart idea!
Unfortunately, building an empty scene didn’t do anything different — I still have the same errors.
I was really hoping that was going to work.
I’m about to try IL2CCP.

@Baste

Finally, this is why you use source control. If you’d been using git or svn, you could go back to earlier commits and run builds with them in a binary-search fashion, which would allow you to pretty quickly pinpoint which commit was the problem, rather than having to consider all of your changes as a whole.

Yeah…
I was using Unity Collaborate for a while as a simple backup system, but then it just broke one day and I was like: “Well, I didn’t really need that… I’ll move to a proper version control later! What could go wrong?”

The moral of this story is: that mindset will make you regret every second of your life.

As an aside,
Have you tried Plastic SCM? There seems to be some caveats to using it , but it may be worth checking out.
Either way — I need to Git Gud, or Git Hub.

[Baste]

I haven’t. We’ve looked into it, but the advantages it offers over git (which we use) didn’t seem to be large enough to make it worthwhile for us to reeducate the entire team to use a new version control software.

The cool thing with git is that for a personal project, you don’t need to have a server you’re pushing stuff to, which reduces cost and removes having to deal with accounts and passwords and all that. You just make commits locally. It essentially becomes regular backups where you write what you did before each backup.

[Tautvydas-Zilys]

Can you tell me where you see the stack overflow error? If Visual Studio didn’t catch it, does that mean Unity doesn’t actually crash?

[Ryanc_unity]

@NotaNaN

Something tells me it is “my fault” because if I remove all of my scripts from my project the build succeeds without error.
I know. It’s a bad sign.

Can you report a fogbug with your project scripts attached. This seems to be an issue in the script meta data generator that is new in 2020.2.

[NotaNaN]

I’m so popular today!

@Baste

I haven’t. We’ve looked into it, but the advantages it offers over git (which we use) didn’t seem to be large enough to make it worthwhile for us to reeducate the entire team to use a new version control software.

The cool thing with git is that for a personal project, you don’t need to have a server you’re pushing stuff to, which reduces cost and removes having to deal with accounts and passwords and all that. You just make commits locally. It essentially becomes regular backups where you write what you did before each backup.

Thanks for telling me about your experiences with Git, @Baste . I’ll probably use that one and make moving to it my “Over-the-Weekend” project for this Saturday.

@Tautvydas-Zilys

Can you tell me where you see the stack overflow error? If Visual Studio didn’t catch it, does that mean Unity doesn’t actually crash?

The Stack Overflow error is in the Unity console.
And yes, Unity doesn’t crash.
To be super specific — if I were to open Build Settings and then press Build, Unity would start building away, throw the Stack Overflow error partway through, and then finish the build, successfully.

If you were to run the build (the generated .exe file), however, Null Reference Exceptions would be thrown. This thread over here was a byproduct of that, and as I boiled the issue down, I made this one and resolved the other.

@Ryanc_unity

Can you report a fogbug with your project scripts attached. This seems to be an issue in the script meta data generator that is new in 2020.2.

Hi, and welcome to my thread.
Quick question — what is a fogbug?
I’m also assuming you want the whole project so that way you can build and see the error for yourself, right? Or do you really just want the scripts?
…
I’m just gonna give you the scripts.

[Ryanc_unity]

@NotaNaN

Hi, and welcome to my thread.
Quick question — what is a fogbug?
I’m also assuming you want the whole project so that way you can build and see the error for yourself, right? Or do you really just want the scripts?

Sorry, fogbug is the internal bug tracker name. Just report a bug via unity and it will end up in there. So if that is what I think it is based on the logs, I just need the scripts/assemblies in your project. No assets as BuildPlayerDataGenerator is just working with the compiled assemblies from your scripts. So I should be able to repro the issue in that log with just the scripts/assemblies.

The gist is that the BuildPlayerDataGenerator process is generating meta data about the compiled / project assemblies that asset with the content build pipeline. If this generates data incorrectly, or in your case crashes, then that would certainly cause the player to be built incorrectly as a result. Before Unity 2020.2, the code of this process was fully inside of the Unity Editor code base and process. We moved it externally to allow us to run it on demand, and cache results on a per assembly basis which will unlock us being able to create a much better incremental player build experience in the future. Still a lot more work to do on that last front.

[NotaNaN]

@Ryanc_unity

Sorry, fogbug is the internal bug tracker name. Just report a bug via unity and it will end up in there. So if that is what I think it is based on the logs, I just need the scripts/assemblies in your project. No assets as BuildPlayerDataGenerator is just working with the compiled assemblies from your scripts. So I should be able to repro the issue in that log with just the scripts/assemblies.

Right-o!
A report has been made, so you should receive it shortly!
Thanks for taking a look!

EDIT 1:
Oops, here’s the case number: 1288883

Sorry, I forgot that part.
I got excited.