StackOverflowException when compiling with FSharp.Compiler.Tools 4.1.1

[alfonsogarciacaro]

This seems to be a regression in the latest release of FSharp.Compiler.Tools (4.1.1).

After upgrading to latest FSharp.NET.Sdk (1.0.2 which has a dependency of FSharp.Compiler.Tools 4.1.1), when I build Fable and use it on a big project I get a StackOverflow exception. Unfortunately, because I cannot catch the exception I don't know exactly where it occurs but I have added logs to all my recursive functions and no one is repeating itself too much. The problem doesn't occur if I downgrade to FSharp.NET.Sdk 1.0.1 (which depends on FSharp.Compiler.Tools 4.1.10).

Repro steps

1. Clone Fable narumi branch using this commit and build the project with the FAKE build script.

2. Start the Fable server by typing dotnet build/fable/dotnet-fable.dll start on the repo root.

3. In a new shell, go to the src/dotnet/Fable.Client.Browser/demo folder and type npm run build.

4. After some seconds a StackOverflow exception will crash the Fable server process. If you use this commit instead (which just downgrades FSharp.NET.Sdk) and repeat steps 1, 2 and 3, the crash won't happen.

Related information

• Windows
• FSharp.Compiler.Tools 4.1.1
• dotnet SDK 1.0.1
• Indications of severity: Serious

[forki]

For the sake of making it very easy for contributors to reproduce: could you please upload a zip with everything restored so that a single command can reproduce the bug? Thanks Am 22.03.2017 22:12 schrieb "Alfonso Garcia-Caro" <notifications@github.com

…

: This seems to be a regression in the latest release of FSharp.Compiler.Tools (4.1.1). After upgrading to latest FSharp.NET.Sdk (1.0.2 which has a dependency of FSharp.Compiler.Tools 4.1.1), when I build Fable and use it on a big project I get a StackOverflow exception. Unfortunately, because I cannot catch the exception I don't know exactly where it occurs but I have added logs to all my recursive functions and no one is repeating itself too much. The problem doesn't occur if I downgrade to FSharp.NET.Sdk 1.0.1 (which depends on FSharp.Compiler.Tools 4.1.10). Repro steps 1. Clone Fable narumi branch using this commit <fable-compiler/Fable@e57a67d> and build the project with the FAKE build script. 2. Start the Fable server by typing dotnet build/fable/dotnet-fable.dll start on the repo root. 3. In a new shell, go to the src/dotnet/Fable.Client.Browser/demo folder and type npm run build. 4. After some seconds a StackOverflow exception will crash the Fable server process. If you use this commit <fable-compiler/Fable@b6678d7> instead (which just downgrades FSharp.NET.Sdk) and repeat steps 1, 2 and 3, the crash won't happen. Related information - Windows - FSharp.Compiler.Tools 4.1.1 - dotnet SDK 1.0.1 - Indications of severity: Serious — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2682>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNACselSQGe9sYoHDfsLEnY4BdRXNks5roZy8gaJpZM4Ml5Ct> .

[alfonsogarciacaro]

My Fable folder is already 1.6GB ;) But I have prepared a trimmed version only with the things you should need (I've also added the FCS code that's necessary to build Fable's REPL), you can download it from here. After unzipping, please make sure you have dotnet SDK installed and then do steps 2 and 3 listed above.

[vasily-kirichenko]

Could you attach to the process with the debugger while it's alive? I believe it should show (very long) stack trace as SO raises.

[alfonsogarciacaro]

I've attached the debugger, and pausing it I get the following screenshot:

As you can see, there's some deep recursion happening to parse big AST expressions, but it's not in the number of hundreds of calls so I guess this shouldn't blow the stack.

However, letting the process run and pausing it later (a bit before it crashes I get):

In this case for a couple of workers "The maximum number of stack frames supported by Visual Studio has been exceeded", so I don't know how big the stack is for them. Is there another way to investigate it? I don't know either if the max number of stack frames supported by Visual Studio is close to what can cause a SO or not. But what puzzles me is this happens when building Fable with F# compiler 4.1.1 and not with 4.1.0. What could have happened in between that has caused this? Is there a tailcall optimization failing?

[vasily-kirichenko]

Use ProcDump https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx Run it for watching your process, when the process crashes, it saves a dump. The dump can be opened in VS to debug.

procdump -ma -e <your process name>.exe

[alfonsogarciacaro]

UPDATE: If I'm not messing up the builds. It seems the SO also occur when building Fable with F# compiler 4.1.0 with Debug config (but not in Release). With F# compiler 4.1.1 it happens both in Debug and Release configs (in previous F# compiler versions the problem didn't seem to happen at all).

I've created a new zip with FAKE build targets so you can try the different configs. As before, after each build run steps 2 and 3 mentioned above to see the crash happen.

BuildDebug_4.1.0
BuildRelease_4.1.0
BuildDebug_4.1.1
BuildRelease_4.1.1

The only target that doesn't cause the SO is BuildRelease_4.1.0

[alfonsogarciacaro]

@vasily-kirichenko Thanks! Where's the dump file saved? I only see this:

[vasily-kirichenko]

I think somewhere in Dump folder: ... :)

[alfonsogarciacaro]

Hmm, I cannot find that Dump folder anywhere. Even giving the dump file a name (procdump -ma -e dotnet.exe fable_fcs.dmp) I cannot find it anywhere on my hard drive. Maybe the last message ("Dump count not reached") means the dump file hasn't been created?

[vasily-kirichenko]

Yeah, looks like it just outputs exceptions to the console. Play with cmd arguments. I forget the exact combination.

[enricosada]

add -g for managed

with filter on first SO is (but try without filter maybe)

procdump -ma -e 1 -f C00000FD.STACK_OVERFLOW -g -w <your process name>.exe

[alfonsogarciacaro]

Thanks @enricosada. I found the same info in SO (the site). Unfortunately, when debugging the dump file with VS it tells me the source is not available, and I cannot read assembly :(

I've uploaded the dump file here in case you make better use of it.

[vasily-kirichenko]

Managed stuff was not dumped

[vasily-kirichenko]

There is a registry key where you can put a process name and a dump will be created every time it crashes. It produces better dumps. I completely forget where it is :(