Burst GetHashCode Stackoverflow when building, 2022.3.42f, Burst 1.8.17

Hi there,
Build had no issue in 2021, 2022 migration brought us the issue

Unity end the build with a stackoverflow. We tried downgrading the packages to the one we had in 2021 LTS but the issue is still here.

UnityEditor.Build.BuildFailedException: Burst compiler (1.8.17) failed running

stdout:
stderr:

Process is terminated due to StackOverflowException.

  at Unity.Burst.Editor.BurstAotCompiler+BclRunner.RunProgram (UnityEditor.Utils.Program p, System.String exe, System.String args, System.String workingDirectory, UnityEditor.Scripting.Compilers.CompilerOutputParserBase parser, System.Boolean unreliableExitCode) [0x00267] in .\Library\PackageCache\com.unity.burst@1.8.17\Editor\BurstAotCompiler.cs:1987 
  at Unity.Burst.Editor.BurstAotCompiler+BclRunner.RunManagedProgram (System.String exe, System.String args, System.String workingDirectory, UnityEditor.Scripting.Compilers.CompilerOutputParserBase parser, System.Collections.Generic.IReadOnlyDictionary`2[TKey,TValue] environment) [0x0009f] in .\Library\PackageCache\com.unity.burst@1.8.17\Editor\BurstAotCompiler.cs:1845 
  at Unity.Burst.Editor.BurstAotCompiler+BclRunner.RunManagedProgram (System.String exe, System.String args, UnityEditor.Scripting.Compilers.CompilerOutputParserBase parser, System.Collections.Generic.IReadOnlyDictionary`2[TKey,TValue] environment) [0x00001] in .\Library\PackageCache\com.unity.burst@1.8.17\Editor\BurstAotCompiler.cs:1806 
  at Unity.Burst.Editor.BurstAotCompiler.OnPostBuildPlayerScriptDLLsImpl (Unity.Burst.Editor.BurstAotCompiler+BurstAOTSettings settings, UnityEditor.Compilation.Assembly[] playerAssemblies) [0x00a5d] in .\Library\PackageCache\com.unity.burst@1.8.17\Editor\BurstAotCompiler.cs:895 

Please see winDbg images,

Are there any file of interest that we could look into ? Some Burst logs? Any pointers are welcome to clear this as we can’t go forward.

Well, this is difficult to debug since the overflow happened in a nested method. Though since it happens in the cecil library, it has to be something to do with some post processing stuff. Do you have networking code in your project? Do you have any self-referencing datastructures that may be send over the network?

It looks like it tries to parse through some kind of data structure and maybe build or calculate the native size of the required data structure. Though since there may be a circular dependency between some types and all that data is serialized, it runs into a stack overflow as it traverses the type recursively. Though that’s just a wild guess.

You said you migrated your project mid-development to a new version? That’s generally not recommended. Does that also mean you don’t have any backup of your pre-migration project? That would be wild -.-

The migration between versions could include some automatic migration script which may change some of your code. If you don’t have a backup or source control to compare against this will certainly be fun to work out :slight_smile: Good luck.

ps: You know that you can use git completely local inside your project. You can commit your changes regularly and it’s all still contained in the same folder, but you have a complete history of all commits you made.

Hey thanks, no beginner there (I mean do beginners uses WinDbg ?), so no issue on the versioning. We know the drill. The upgrade to 2022 was mainly due to other locking and cumbersome issues. Also being on par with latest updates is something you want in the end, in order to actually get sure to have the latest support and features. We’re a small team so we can afford the flexibility and upgrade costs. 2021 LTS will have a longer support as initially expected, but so will 2022 in comparison to 21

Back to the subject, no we don’t have anything to do with network code. We upgraded unity Collections package as it was still on an old version post upgrade but it is not changing the problem, I was pretty sure it would get rid of the issue but unfortunately no.

Also I’m not sure to follow this train of thoughts as how it could be related to PP or Networking ? If I didn’t know better I’d say it’s an AI based reply :stuck_out_tongue_closed_eyes:

Though since it happens in the cecil library, it has to be something to do with some post processing stuff. Do you have networking code in your project? Do you have any self-referencing datastructures that may be send over the network?

However something is doing a Type recursion.

We reported this with a dump at the exact location and the according log file : IN-83253

Maybe @tim_jones would you have some insights on this ?

Could be related to this one as well on the Hashing ground.

Also the start of the stacktrace :

...
31b1 000000e7`d8afe7a0 00007ff8`dbf2404b     Unity_Burst_Cecil!Mono.Cecil.MetadataResolver.GetType+0xeb
31b2 000000e7`d8afe7f0 00007ff8`dbf2404b     Unity_Burst_Cecil!Mono.Cecil.MetadataResolver.GetType+0xeb
31b3 000000e7`d8afe840 00007ff8`dbcd4efa     Unity_Burst_Cecil!Mono.Cecil.MetadataResolver.GetType+0xeb
31b4 000000e7`d8afe890 00007ff8`dbf744da     Unity_Burst_Cecil!Mono.Cecil.TypeReference.Resolve+0x3a
31b5 000000e7`d8afe8c0 00007ff8`dbf74581     Burst_Compiler_IL!Burst.Compiler.IL.Server.EntryPointMethodFinder.CollectGenericTypeInstances+0xaa
31b6 000000e7`d8afe940 00007ff8`dbf655b9     Burst_Compiler_IL!Burst.Compiler.IL.Server.EntryPointMethodFinder.CollectGenericTypeInstances+0x151
31b7 000000e7`d8afe9c0 00007ff8`dbcb9f21     Burst_Compiler_IL!Burst.Compiler.IL.Server.EntryPointMethodFinder.CollectGenericTypeInstances+0x109
31b8 000000e7`d8afeaa0 00007ff8`dbcb6b5b     Burst_Compiler_IL!Burst.Compiler.IL.Server.EntryPointMethodFinder.FindEntryPoints+0x6b1
31b9 000000e7`d8afedd0 00007ff8`dbcae91a     Burst_Compiler_IL!Burst.Compiler.IL.Server.CompilerServer.<>c__DisplayClass18_1.<FindMethods>b__0+0xeb
31ba 000000e7`d8afee70 00007ff8`dbcae284     Burst_Compiler_IL!Burst.Compiler.IL.Server.CompilerServer.<>c__DisplayClass26_0<System.__Canon>.<<RunTask>b__0>d.MoveNext+0xba
31bb 000000e7`d8afeef0 00007ff8`dbcae192     mscorlib_ni!System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.__Canon>.Start<<<RunTask>b__0>d>+0xa4 [f:\dd\ndp\clr\src\BCL\system\runtime\compilerservices\AsyncMethodBuilder.cs @ 471] 
31bc 000000e7`d8afefb0 00007ff9`3a28ddce     Burst_Compiler_IL!Burst.Compiler.IL.Server.CompilerServer.<>c__DisplayClass26_0<System.__Canon>.<RunTask>b__0+0x82
31bd 000000e7`d8aff030 00007ff9`3a259d47     mscorlib_ni!System.Threading.Tasks.Task<System.__Canon>.InnerInvoke+0x4e [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Future.cs @ 680] 
31be 000000e7`d8aff080 00007ff9`3a230bf8     mscorlib_ni!System.Threading.Tasks.Task.Execute+0x47 [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2498] 
31bf 000000e7`d8aff0c0 00007ff9`3a230ae5     mscorlib_ni!System.Threading.ExecutionContext.RunInternal+0x108 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 980] 
31c0 000000e7`d8aff190 00007ff9`3a25adc1     mscorlib_ni!System.Threading.ExecutionContext.Run+0x15 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 928] 
31c1 000000e7`d8aff1c0 00007ff9`3a259e91     mscorlib_ni!System.Threading.Tasks.Task.ExecuteWithThreadLocal+0x231 [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2827] 
31c2 000000e7`d8aff270 00007ff8`dbca3110     mscorlib_ni!System.Threading.Tasks.Task.ExecuteEntry+0xa1 [f:\dd\ndp\clr\src\BCL\system\threading\Tasks\Task.cs @ 2767] 
31c3 000000e7`d8aff2b0 00007ff9`3a230bf8     Burst_Compiler_IL!Burst.Compiler.IL.Server.CompilerThread.CompilerThreadLoop+0x240
31c4 000000e7`d8aff370 00007ff9`3a230ae5     mscorlib_ni!System.Threading.ExecutionContext.RunInternal+0x108 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 980] 
31c5 000000e7`d8aff440 00007ff9`3a230ab5     mscorlib_ni!System.Threading.ExecutionContext.Run+0x15 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 928] 
31c6 000000e7`d8aff470 00007ff9`3a255445     mscorlib_ni!System.Threading.ExecutionContext.Run+0x55 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 917] 
31c7 000000e7`d8aff4c0 00007ff9`3b4712c3     mscorlib_ni!System.Threading.ThreadHelper.ThreadStart+0x55 [f:\dd\ndp\clr\src\BCL\system\threading\thread.cs @ 111] 
31c8 000000e7`d8aff500 00007ff9`3b33961b     clr!CallDescrWorkerInternal+0x83
31c9 000000e7`d8aff540 00007ff9`3b388b5a     clr!CallDescrWorkerWithHandler+0x47
31ca 000000e7`d8aff580 00007ff9`3b681659     clr!MethodDescCallSite::CallTargetWorker+0xfa
31cb 000000e7`d8aff680 00007ff9`3b35230b     clr!ThreadNative::KickOffThread_Worker+0x2186d9
31cc 000000e7`d8aff8d0 00007ff9`3b35222f     clr!ManagedThreadBase_DispatchInner+0x33
31cd 000000e7`d8aff910 00007ff9`3b3520fb     clr!ManagedThreadBase_DispatchMiddle+0x83
31ce 000000e7`d8affa00 00007ff9`3b35206f     clr!ManagedThreadBase_DispatchOuter+0x87
31cf 000000e7`d8affa90 00007ff9`3b469e11     clr!ManagedThreadBase_FullTransitionWithAD+0x2f
31d0 000000e7`d8affaf0 00007ff9`3b4558ea     clr!ThreadNative::KickOffThread+0xe1
31d1 000000e7`d8affbb0 00007ff9`5cd87374     clr!Thread::intermediateThreadProc+0x8a
31d2 000000e7`d8affe70 00007ff9`5e2bcc91     kernel32!BaseThreadInitThunk+0x14
31d3 000000e7`d8affea0 00000000`00000000     ntdll!RtlUserThreadStart+0x21