[Bug]: Building a .NET Core Function SDK 8.0.201 on a MAC with M1 chip

[HeHubo]

Issue Description

Currently I getting an error while try to build my azure function project with the .NET SDK 8.0.201. I use an MAC with an M1 chip. On a Windows device with windows 11, the build runs successful.

I try many thinks to fix this error:

• Reinstall SDK
• Reinstall Rider
• Reset and a complete new installation of the Mac OS

Steps to Reproduce

• Open the project
• Build in Jetbrains Rider or VS Code
• getting this error

Expected Behavior

should compile ;-)

Actual Behavior

Error CS 8078 occurs

Analysis

No response

Versions & Configurations

MSBuild version 17.9.4+90725d08d for .NET
SDK 8.0.201

[jaredpar]

Unfortunately on .NET 8 and earlier the default stack size on Mac machines is much smaller than Windows / Linux. That means the compiler, which is naturally recursive in places, can run into limitations on Mac that it doesn't hit on other OS. That appears to be what is happening here.

If possible would you be able to share the file in question here? I want to see if there is a particular pattern that we could recommend the function team change to make it harder to hit this issue.

Note: in .NET 9 the situation should improve as the runtime team took steps to normalize stack space across OS

[HeHubo]

The problem is that I can't tell exactly which file or files are causing this error. Only a reduction of the files in the function project brings success. Perhaps the problem could also come from the fact that our function has between 300 and 400 APIs. I am not aware of any complex code that could cause this stack overflow.

[jaredpar]

@HeHubo based on the screen shot it's from a generated file called GeneratedFunctionExecutor.g.cs. I'm not 100% sure what is producing that but the file will either be in one of two places:

1. Inside the obj directory, maybe in obj\Debug.
2. If a source generator file then passing -p:EmitCompilerGeneratedFiles=true on the command line will put the file in the obj directory

If this is code you can share out I'm happy to take a quick look at it and just find the file for you. If you need to share privately can file a VS Feedback issue, post the link here and we can get it going from that point.

[HeHubo]

After I setting the EmitCompilerGeneratedFiles property in the project file, the build creates the file with the error.

Here is the file:
GeneratedFunctionExecutor.g.cs.zip

[jaredpar]

@cston looking at the generated code here, i'm not seeing the usual candidates for why the compiler hits stack limits. There is a very long chain of else if in an async method but I'd be surprised if that caused deep stack recursion.

[cston]

It looks like the parser will fail if there are too many else if cases.

For instance, the following results in error CS8078: An expression is too long or complex to compile beyond a certain number of cases, even with earlier builds of the compiler.

class Program
{
    static void F(int i)
    {
        if (i == 0) { }
        else if (i == 0) { }
        else if (i == 0) { }
        else if (i == 0) { }
        /* ... */
    }
}

[jaredpar]

That seems like something we should fix. There are limits that are hard to fix with nested exprs but chained statements like this should be oka.y

[cston]

An else if statement is represented as an if statement nested in the enclosing else. To remove the limit on the number of else if cases, we'll need to update the parser and also update binding and lowering to handle arbitrarily deeply nested IfStatementSyntax.

[Solxanich]

Also experiencing this chained else if on tModLoader project.
Wondering if there is an estimated timeline on this?

We had to forcefully downgrade to SDK 8.0.102 for our project to build in CI, so we do have a workaround, but it sounds like this could show up again if cross a magic number of chain length.
tModLoader/tModLoader@0eb2a4c

Erroring build:
https://github.com/tModLoader/tModLoader/actions/runs/8023721868

Referenced line is ~75% way through an else if chain spanning 8000+ lines / 600+ else-if.

We've also observed that Visual Studio based Build / Debugging does not trigger this issue compared to dotnet build. Not sure what exactly is different, but may be useful?

[jaredpar]

Wondering if there is an estimated timeline on this?

A fix for this is likely to show up in the VS 17.11 / .NET SDK 8.0.300 timeframe.

https://github.com/tModLoader/tModLoader/actions/runs/8023721868

How do you get the source for that file?

We've also observed that Visual Studio based Build / Debugging does not trigger this issue compared to dotnet build

That is a little surprising. The original bug filed here was due to compiling on Mac. The stack size on a Mac is significantly smaller than Windows / Linux hence hitting stack limitations in the compiler is more common there. The same stack size applies to msbuild and dotnet build on Windows. Having one crash and one not suggests the code was already right on the edge of the Windows limit but a subtle change in the new compiler pushed it over the limit.

[Mirsario]

A fix for this is likely to show up in the VS 17.11 / .NET SDK 8.0.300 timeframe.

Great to hear!

How do you get the source for that file?

The actual source file causing us the error comes from a game modding project, which, while open source in patch form, we aren't allowed to publicly distribute the source files for. I can provide the source-code privately via email if you would like.
Or, if by chance you happen to own a Steam Windows copy of Terraria - the basic instructions for using our development setup tool (decompiler + patcher) are here.

Since we operate on patches, it's not very ideal for us to introduce new ones to split up functions into smaller parts, but we may do that in this case, as it seems like it's only one function that is failing to compile. That comes to my surprise however, as a lot of the game's logic happens to be unbelievably large else-if chains, and so yes, our project has most likely always been close to the compiler's limits. 🙃

[jaredpar]

I can provide the source-code privately via email if you would like.

You can send to [email protected] or open a VS feedback ticket, upload there and post a link in this issue. Either works for me.

[cston]

To support arbitrary length chains of else if statements, we'll need to update various visitors in the compiler that walk syntax or bound nodes to avoid recursion for nested if statements. The set of visitors includes:

• LanguageParser
• Binder
• LocalBinderFactory
• LocalRewriter
• Optimizer
• AbstractFlowAnalysis
• CSharpOperationFactory

[CyrusNajmabadi]

@cston for the ide, the set would also need to handle SyntaxWalker and SyntaxRewriter. Ide will likely die immediately due to our dependency on those compiler types, and their recursive behavior.

[hamza-abdullah-ss]

We have observed that when using MSBuild instead of dotnet build the build completes successfully, I assume this is what VS is using internally as well? and therefore why people including us can't recreate in the IDE, also we're seeing this on Windows as well

[hamza-abdullah-ss]

And in our case it seems to be linked with the number of Azure Functions we have 500+ in the project

[vinid223]

We are having the same issue after migrating our Azure Function App from .net 6 in-process to .Net 8 isolated.

As a workaround for now (for those developing Azure Function), downgrading the package Microsoft.Azure.Functions.Worker.Sdk to 1.16.2 seems to do the trick. It starts failing to build starting in version 1.16.3.

It's definitely not a fix, but it allows the build to work.