ArgumentOutOfRangeException from SA1518

[am11]

In @AaronRobinsonMSFT's PR dotnet/runtime#113715, we started to see SA1518 false-positives followed by ArgumentOutOfRangeException. From dotnet build -v:diag:

16.55.32.912     9>CSC : error AD0001: Analyzer 'StyleCop.Analyzers.LayoutRules.SA1518UseLineEndingsCorrectlyAtEndOfFile' threw an exception of type 'System.ArgumentOutOfRangeException' with message 'Specified argument was out of the range of valid values. (Parameter 'span')'. [/Users/adeel/projects/runtime5/src/coreclr/System.Private.CoreLib/System.Private.CoreLib.csproj]
                     Exception occurred with following context: (TaskId:448)
                     Compilation: System.Private.CoreLib (TaskId:448)
                     SyntaxTree: /Users/adeel/projects/runtime5/src/coreclr/System.Private.CoreLib/src/System/GC.CoreCLR.cs (TaskId:448)
                     System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (Parameter 'span') (TaskId:448)
                     at Microsoft.CodeAnalysis.Text.SourceText.CheckSubSpan(TextSpan span) (TaskId:448)
                     at Microsoft.CodeAnalysis.Text.SourceText.ToString(TextSpan span) (TaskId:448)
                     at StyleCop.Analyzers.LayoutRules.SA1518UseLineEndingsCorrectlyAtEndOfFile.HandleSyntaxTree(SyntaxTreeAnalysisContext context, StyleCopSettings settings) (TaskId:448)
                     at Microsoft.CodeAnalysis.Diagnostics.AnalyzerExecutor.<>c.<ExecuteSyntaxTreeActions>b__50_1(ValueTuple`2 data) (TaskId:448)
                     at Microsoft.CodeAnalysis.Diagnostics.AnalyzerExecutor.ExecuteAndCatchIfThrows_NoLock[TArg](DiagnosticAnalyzer analyzer, Action`1 analyze, TArg argument, Nullable`1 info, CancellationToken cancellationToken) (TaskId:448)
                     ----- (TaskId:448)

which seems likely to be coming from:

StyleCopAnalyzers/StyleCop.Analyzers/StyleCop.Analyzers/LayoutRules/SA1518UseLineEndingsCorrectlyAtEndOfFile.cs

Line 147 in f5843ae

string trailingWhitespaceText = sourceText.ToString(reportedSpan);

(there are no debug symbols for line info, so it's a guess)
The workaround was to apply this patch:

diff --git a/src/coreclr/System.Private.CoreLib/src/System/GC.CoreCLR.cs b/src/coreclr/System.Private.CoreLib/src/System/GC.CoreCLR.cs
index 7654b65dec4..184ce80f44b 100644
--- a/src/coreclr/System.Private.CoreLib/src/System/GC.CoreCLR.cs
+++ b/src/coreclr/System.Private.CoreLib/src/System/GC.CoreCLR.cs
@@ -2,14 +2,9 @@
 // The .NET Foundation licenses this file to you under the MIT license.
 
 /*============================================================
-**
-**
-**
 ** Purpose: Exposes features of the Garbage Collector through
 ** the class libraries.  This is a class which cannot be
 ** instantiated.
-**
-**
 ===========================================================*/

on top of this version of the file: https://github.com/dotnet/runtime/blob/e608b893b83672efcf4dec4ebf3d0e0ac6c1ba2e/src/coreclr/System.Private.CoreLib/src/System/GC.CoreCLR.cs

[bjornhellander]

Did this happen consistently or was it intermittent?

[am11]

@bjornhellander, it was intermittent. In my experiment, it was happening one in clean three tries on mac: dotnet/runtime#113715 (comment). Basically killing those processes (especially VBCSCompiler which runs in the background and papers over the issue) was the key to repro it slightly more reliably.

And in the CI, random legs were failing in each run.

[bjornhellander]

The fact that killing the compiler service affects this behavior is a bit worrying. This rule has no state that should affect whether or not the exception happens. It does cache settings which affect what the rule considers to be a correct file ending, but this exception happens before that setting has been used. So I don't see anything that could be non-deterministic in it.

Could you probide a branch with the commit you mention? I have tried to create one locally but I don't seem to get that specific commit when I clone.

[bjornhellander]

I had a quick look at the solution and I think that at least I would need something much simpler than this to be able to have a look at your problem. If you could create a simple class library with this file as it was with minimal code around it to make it compile and still be able to reproduce the problem sometimes, then I would gladly have a look, but given how much complexity there is in this solution right now, I can't spend the time on this. So a minimal solution which still reproduces the problem sometimes would be required for me at least.

[am11]

I understand. Unfortunately, the runtime build is pretty complex, so isolating intermittent issue like this one isn't trivial. @jjonescz and co have been updating roslyn toolchain in runtime repo, so it may ring a bell. I just wanted to report the issue so there is a record if someone else hits it in the future, and to make sure it isn't lost in unrelated PR discussion. It was first discovered in the runtime CI with Aaron's change which had no trailing whitespace and neither there was any in rest of the file. We found that workaround (removing ** comment lines) by trial and error.

[jkotas]

This is likely a GC heap corruption given the symptoms. Transferring to dotnet/runtime.

It may be related to dotnet/runtime#112613 .

[jkotas]

Transferring to dotnet/runtime.

Ah, this is under DotNetAnalyzers org. Github won't allow me to transfer the issue from here.