64-bit fscAnyCpu.exe uses more stack than 32-bit fsc.exe (was: Project that builds in VS2019 fails to build in VS2022)

[kentcb]

A project that is part of a reasonably complex solution is failing to build in 2022 due to the compiler crashing. I've managed to boil things down to a simple, standalone repro shown below.

Repro steps

The following simplified code typifies that which is causing the compiler to crash:

module repro_fscanycpu_failure

//
// This builds fine in VS2019, but fails under VS2022 with:
//
// 1>  Process is terminated due to StackOverflowException.
// 1>  C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\CommonExtensions\Microsoft\FSharp\Tools\Microsoft.FSharp.Targets(317,9): error MSB6006: "fscAnyCpu.exe" exited with code -1073741571.
//
// Opening this file in the VS2022 editor will also crash, presumably for the same underlying reason.
//

type ReproBuilder () =
    member _.Delay x = x ()
    member _.Yield  (x) = x
    member _.Combine (x, y) = x + y

let repro = ReproBuilder ()

let callSite () =
    repro {
        // Commenting out some of the below is enough to avoid StackOverflow on my machine.
        0
        1
        2
        3
        4
        5
        6
        7
        8
        9
        0
        1
        2
        3
        4
        5
        6
        7
        8
        9
        0
        1
        2
        3
        4
        5
        6
        7
        8
        9
        0
        1
        2
        3
        4
        5
        6
        7
        8
        9
        0
        1
        2
        3
        4
    }

Expected behavior

It should build in 2022 as it does in 2019.

Actual behavior

It fails with:

1>C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\CommonExtensions\Microsoft\FSharp\Tools\Microsoft.FSharp.Targets(317,9): error MSB6006: "fscAnyCpu.exe" exited with code -1073741571.

Known workarounds

1. Short-term fix: Use VS2019.

2. Recommended: Make your inputs smaller, probably half the size will do, divide your large expressions into two

Related information

Provide any related information (optional):

• Windows 10
• .NET Core

[smoothdeveloper]

@kentcb just in case it has an impact, can you try compiling the same project in Release mode (assuming it was Debug mode you tried)?

[kentcb]

@smoothdeveloper Alas, same problem.

[eriawan]

@kentcb
I think this is something related to TFM of the nuget package you used.
Have you updated the microsoft.servicefabric nuget package? I've used version 8.1.335 and I have no problem.

See also
https://www.nuget.org/packages/Microsoft.ServiceFabric/8.1.335

[cartermp]

@kentcb if you're allowed to build with the /bl flag and upload the binlog then that makes it a lot easier for folks to diagnose.

[vzarytovskii]

@kentcb if you're allowed to build with the /bl flag and upload the binlog then that makes it a lot easier for folks to diagnose.

Yeah, binlog or minimal repro would be ideal.

[kentcb]

@eriawan Yes, I did try upgrading to latest Microsoft.ServiceFabric.Services.Remoting to no avail. I've also tried to extract this into a minimal repro, but no luck.

Happy to upload a binlog, but is there somewhere private I can upload it or someone I can share a OneDrive link with?

[kentcb]

By building with more diagnostics, I could see that fsAnyCpu.exe was terminating due to stack overflow when building my Types project. By process of elimination, I identified which file was causing the crash. Even opening this file in the editor would eventually crash VS, so I had to edit it in VS2019, but doing so allowed me to identify the code that was triggering the regression...

It's a custom CE we use to define codecs. We use it extensively throughout our entire solution, and yet this one particular case was causing a SO. By playing around with it, I determined that there was no particular line triggering the SO, but rather the sheer number of them. It was happy with up to 38 lines, but the 39th would trigger a crash (either in editor, or in compiler, so presumably the same SO crash).

Of course, there must be something our CE is doing, or something about what we're doing on each line to trigger the SO. And of course, something about FSC must have changed such that this is crashing where it never previously did. That's where I'm at and will possibly handball this issue internally.

[jimfoye]

Perhaps related to #9231?

[kentcb]

@jimfoye Hmm, maybe, but I use Windows and sounds like it's a non-issue there. I'll try and find some time to repro this in a standalone project later in the week.

[kentcb]

@vzarytovskii @cartermp Please see updated issue description for a simple repro

[dsyme]

@kentcb Thanks for the repro. We'll work on it, we don't have a large-input stress test of that size, and we must be doing something quadratic or worse.

[ly29]

Noticed something similar which crashes Visual Studio 2022 hard.