Unhandled exception. System.IndexOutOfRangeException: Index was outside the bounds of the array.
Using AltCover 9.0.1 via dotnet tool install --global altcover.global. My project is a very large C# .NET 4.8 desktop app with more than 2500 DLLs.
When cd-ing to my \bin folder and executing altcover.exe --verbose I get an exception:
some.dll : beginning process Assembly symbol GUID = d97695fa-e174-4fd2-a9fd-47c0a0c60943 mvid = 92e1e3a8-e691-4bd4-9b5e-f4fd4e7a9ad1 Symbol file some.pdb GUID = d97695fa-e174-4fd2-a9fd-47c0a0c60943 Assembly some.dll symbols from folder '"some.pdb"' Unhandled exception. System.IndexOutOfRangeException: Index was outside the bounds of the array. at Microsoft.Cci.Pdb.PdbFile.ReadSourceFileInfo(BitAccess bits, UInt32 limit, IntHashTable names, MsfDirectory dir, Dictionary
2 nameIndex, PdbReader reader, Dictionary2 sourceCache) at Microsoft.Cci.Pdb.PdbFile.LoadManagedLines(PdbFunction[] funcs, IntHashTable names, BitAccess bits, MsfDirectory dir, Dictionary2 nameIndex, PdbReader reader, UInt32 limit, Dictionary2 sourceCache) at Microsoft.Cci.Pdb.PdbFile.LoadFunctions(Stream read) at Mono.Cecil.Pdb.NativePdbReader.ProcessDebugHeader(ImageDebugHeader header) at AltCover.ProgramDatabase.readSymbols(AssemblyDefinition assembly) in ///AltCover.Engine/ProgramDatabase.fs:line 309 at [email protected](Unit unitVar0) in ///AltCover.Engine/Main.fs:line 578 at AltCover.Main.I.imageLoadResilient[a](FSharpFunc2 f, FSharpFunc2 tidy) in ///AltCover.Engine/Main.fs:line 432 at Microsoft.FSharp.Collections.SeqModule.Fold[T,TState](FSharpFunc2 folder, TState state, IEnumerable1 source) in D:\a_work\1\s\src\FSharp.Core\seq.fs:line 913 at Microsoft.FSharp.Collections.Internal.IEnumerator.map@128.DoMoveNext(b& curr) in D:\a_work\1\s\src\FSharp.Core\seq.fs:line 131 at Microsoft.FSharp.Collections.Internal.IEnumerator.MapEnumerator1.System.Collections.IEnumerator.MoveNext() in D:\a\_work\1\s\src\FSharp.Core\seq.fs:line 113 at Microsoft.FSharp.Collections.SeqModule.ToList[T](IEnumerable1 source) in D:\a_work\1\s\src\FSharp.Core\seq.fs:line 1004 at AltCover.Main.I.prepareTargetFiles(IEnumerable1 inputInfos, IEnumerable1 outputInfos, IEnumerable1 instrumentFromInfos, IEnumerable1 instrumentToPaths) in ///AltCover.Engine/Main.fs:line 560 at [email protected](Unit unitVar0) in ///AltCover.Engine/Main.fs:line 767 at AltCover.PathOperation.DoPathOperation[TAny](FSharpFunc2 operation, FSharpFunc2 handle) in ///AltCover.Engine/Output.fs:line 21 at AltCover.CommandLine.I.doPathOperation[a](FSharpFunc2 f, a defaultValue, Boolean store) in /_//AltCover.Engine/CommandLine.fs:line 200 at [email protected](FSharpFunc2 f, a defaultValue, Boolean store) at AltCover.Main.I.doInstrumentation(String[] arguments) in ///AltCover.Engine/Main.fs:line 760 at AltCover.Main.I.main(String[] arguments) in ///AltCover.Engine/Main.fs:line 835 at [email protected](String[] arguments)
As a workaround I will filter out the offending DLLs.
Maybe a "--ignoreExceptions" switch would come in handy? It could proceed with instrumenting, wherease skipping the failed DLLs. At the end, list all DLLs that were ignored, so that I can simply include them into the filter.
The AltCover.Main.I.imageLoadResilient call through which this filters is a pass that is already implicitly doing an --ignoreExceptions for likely malformed or mismatched symbol files; this appears to be a novel form of .pdb file corruption that doesn't end up raising one of the expected exception types that explicitly state that there is corruption - SymbolsNotMatchingException, BadImageFormatException and the like.
Trying to determine what the issue actually is, going to the source in the Mono.Cecil project - my comment added in quoted section
byte[] checksum = null;
if (nameIndex.TryGetValue("/SRC/FILES/" + name.ToUpperInvariant(), out guidStream))
{
var guidBits = new BitAccess(0x100);
dir.streams[guidStream].Read(reader, guidBits); // << == here
LoadInjectedSourceInformation(guidBits, out doctypeGuid, out languageGuid, out vendorGuid, out checksumAlgoGuid, out checksum);
}
indicates the only direct array reference, when trying to find the information regarding one of the source files.
It would be useful to also raise this as an issue on that project, if you haven't already, so that it can provide appropriate error handling for such cases.
A fix is prepared and will appear in the next release.
Fixed in release v9.0.102