search

oleg-shilo / cs-script

C# scripting platform
http://www.cs-script.net
MIT License
1.57k stars 234 forks source link

compilation hangs! #300

Closed eugene-vv closed 2 years ago

eugene-vv commented 2 years ago

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 commented 2 years ago

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

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 commented 2 years ago

"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 commented 2 years ago

Asking you since you gave me two conflicting messages:

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Closing unless it reappears