compilation hangs!

[eugene-vv]

Hi Oleg,
We met another issue which easy to reproduce but leads to hangs of execution. When we run "cscs.exe somescript.cs" command line and somescript.cs has several errors the process hangs. Looks like problem in analysis of stdout/stderr buffers of child dotnet process. The cscs read them after execution completed but size of buffers by default is small and if dotnet write there a lot information (compilation errors) the buffers become full and wait until they will be read.

[oleg-shilo]

Interestingly enough the script engine does not allocate any buffer but simply reads the output stream as a whole (line 66):

As you can see from the comments there .NET 6 has introduced some new behaviour compared to .NET Framework when it comes to STDOUT and STDERR redirection.

I will see if I can reproduce it.
When you say "there a lot information", how much information is it?

[eugene-vv]

"A lot" means script has so many errors that compiler output takes more then 2K symbols. Ask me if you wont reproduce it. I will send the example

[oleg-shilo]

Asking you since you gave me two conflicting messages:

• "has several errors the process hangs"
• "there a lot information"

You probably can see how "several" and "a lot" are contradicting each other.

And yes a sample (test case) is always a preferred troubleshooting option.

[eugene-vv]

no_ref.cs.zip
I attached example in archive. Just type "cscs no_ref.cs". I used 4.4.3.0 version. You can play just (un)comment line with errors. May be that's important - I use windows version

[oleg-shilo]

Hm..., I cannot reproduce it.

PS D:\dev\support\cs-script-#300> cscs --version
4.4.7.0
PS D:\dev\support\cs-script-#300> cscs -ng:csc .\no_ref.cs
Error: Specified file could not be compiled.

D:\dev\Galos\support\cs-script-#300\no_ref.cs(11,4): error CS0103:  The name 'a' does not exist in the current context
D:\dev\Galos\support\cs-script-#300\no_ref.cs(12,4): error CS0103:  The name 'b' does not exist in the current context
D:\dev\Galos\support\cs-script-#300\no_ref.cs(13,4): error CS0103:  The name 'c' does not exist in the current context
D:\dev\Galos\support\cs-script-#300\no_ref.cs(14,4): error CS0103:  The name 'd' does not exist in the current context
D:\dev\Galos\support\cs-script-#300\no_ref.cs(15,4): error CS0103:  The name 'e' does not exist in the current context
D:\dev\Galos\support\cs-script-#300\no_ref.cs(16,4): error CS0103:  The name 'f' does not exist in the current context
D:\dev\Galos\support\cs-script-#300\no_ref.cs(17,4): error CS0103:  The name 'g' does not exist in the current context
D:\dev\Galos\support\cs-script-#300\no_ref.cs(18,4): error CS0103:  The name 'h' does not exist in the current context
D:\dev\Galos\support\cs-script-#300\no_ref.cs(19,4): error CS0103:  The name 'k' does not exist in the current context
D:\dev\Galos\support\cs-script-#300\no_ref.cs(20,4): error CS0103:  The name 'l' does not exist in the current context

The csc I am using is .NET6 version

PS D:\dev\Galos\support\cs-script-#300> cscs
C# Script execution engine (.NET Core). Version 4.4.7.0.
   . . .
   Compiler engine: csc (C:\Program Files\dotnet\sdk\6.0.301\Roslyn\bincore\csc.dll)
                  : dotnet (C:\Program Files\dotnet\dotnet.exe)
   . . .

While the problem might be triggered by the rest of your environment I am still concerned about csc.exe not returning in your case.

You can try to execute csc.exe directly with the same parameters and see if it exits. If it does then you check (in the hello-world project) if Process.StandardOutput.ReadToEnd() exits.

[eugene-vv]

Hmm, I have updated dotnet to 6.0.6 and cs-script to 4.4.7.0 and problem has gone. Sorry, I think that next investigations are senseless. I have several installed cs-script versions, on 4.4.0.0 the error exists, but this is old version.

[oleg-shilo]

Agree.

It might be related to the v4.4.7 change:

CLI
Fixed the problem with possible double referencing GAC assemblies for CSC engine due to the nuget dependencies on GAC assemblies of the different versions.

If csc was choking on too many assemblies being referenced. Still, it should not choke but exit. Even with the error exit code.
But.... if it works as expected now, then let's just take it as is.

[oleg-shilo]

Closing unless it reappears