Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

DacNameParser.Parse(name) throws System.IndexOutOfRangeException #897

Closed
catstrike opened this issue Feb 26, 2021 · 2 comments
Closed

DacNameParser.Parse(name) throws System.IndexOutOfRangeException #897

catstrike opened this issue Feb 26, 2021 · 2 comments

Comments

@catstrike
Copy link
Contributor

I'm enumerating all the types in a dump with ClrMD 2.0
For one of the types, DAC returns the following name:
StructureMap.Pipeline.ExpressedInstance`3[[StructureMap.Pipeline.LambdaInstance`2, EnforceHttpsModule],T,TPluginType]

DacNameParser can't parse it and throws System.IndexOutOfRangeException.

Unhandled Exception: System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at System.String.get_Chars(Int32 index)
   at Microsoft.Diagnostics.Runtime.Builders.DACNameParser.DetermineNextStateAndPos(String name, Int32 curPos)in C:\Developer\projects\clrmd2\src\Microsoft.Diagnostics.Runtime\src\Common\DACNameParser.cs:line 630
   at Microsoft.Diagnostics.Runtime.Builders.DACNameParser.Parse(String name) in C:\Developer\projects\clrmd2\src\Microsoft.Diagnostics.Runtime\src\Common\DACNameParser.cs:line 165
   at Microsoft.Diagnostics.Runtime.Builders.RuntimeBuilder.Microsoft.Diagnostics.Runtime.Implementation.ITypeHelpers.GetTypeName(UInt64 mt, String& name) in C:\Developer\projects\clrmd2\src\Microsoft.Diagnostics.Runtime\src\Builders\RuntimeBuilder.cs:line 1465
   at Microsoft.Diagnostics.Runtime.Implementation.ClrmdType.get_Name() in C:\Developer\projects\clrmd2\src\Microsoft.Diagnostics.Runtime\src\Implementation\ClrmdType.cs:line 61
   at Microsoft.Diagnostics.Runtime.Implementation.ClrmdType.DebugOnlyLoadLazyValues() in C:\Developer\projects\clrmd2\src\Microsoft.Diagnostics.Runtime\src\Implementation\ClrmdType.cs:line 120
   at Microsoft.Diagnostics.Runtime.Implementation.ClrmdType..ctor(ClrHeap heap, ClrType baseType, ClrModule module, ITypeData data, String name) in C:\Developer\projects\clrmd2\src\Microsoft.Diagnostics.Runtime\src\Implementation\ClrmdType.cs:line 114
   at Microsoft.Diagnostics.Runtime.Builders.RuntimeBuilder.GetOrCreateType(ClrHeap heap, UInt64 mt, UInt64 obj) in C:\Developer\projects\clrmd2\src\Microsoft.Diagnostics.Runtime\src\Builders\RuntimeBuilder.cs:line 1053
   at Microsoft.Diagnostics.Runtime.Builders.RuntimeBuilder.GetOrCreateType(ClrHeap heap, UInt64 mt, UInt64 obj) in C:\Developer\projects\clrmd2\src\Microsoft.Diagnostics.Runtime\src\Builders\RuntimeBuilder.cs:line 1048
   at Microsoft.Diagnostics.Runtime.Builders.RuntimeBuilder.GetOrCreateType(UInt64 mt, UInt64 obj) in C:\Developer\projects\clrmd2\src\Microsoft.Diagnostics.Runtime\src\Builders\RuntimeBuilder.cs:line 995
   at Microsoft.Diagnostics.Runtime.Implementation.ClrmdRuntime.GetTypeByMethodTable(UInt64 methodTable) in C:\Developer\projects\clrmd2\src\Microsoft.Diagnostics.Runtime\src\Implementation\ClrmdRuntime.cs:line 100
   at ClrMD.Playground.Program.<EnumerateTypes>d__11.MoveNext() in C:\Developer\projects\clrmd2\src\ClrMD.Playground\Program.cs:line 297

CLR version: 4.7.2650.0
Architecture: Amd64
@leculver
Copy link
Contributor

@ryanmolden Do you have some time to take a look? I'll likely put a try catch at the bottom of Parse in the next release either way.

@leculver leculver mentioned this issue Mar 19, 2021
Merged
leculver added a commit that referenced this issue Mar 19, 2021
@leculver
Catch exception when parsing dac names (#904)
877919b 
Wrap Dac name parsing in a try/catch.  Historically parsing all of the various type names has been a real pain point.  We need to fix the underlying exception but for now we'll wrap the method in a try/catch to ensure it doesn't unexpectedly throw.

Contributes to #897.
@ryanmolden
Copy link
Member

@leculver wow, I never use GitHub (sorry), so I never saw this tag. Anyhow, ironically I am running into the same issue here, the problem is the non-assembly qualified names (T and TPluginType). The parser assumes all generic args will be assembly qualified (i.e. [Foo, Bar]), which clearly is not true. I am working on a fix but as you stated in the fix to add the catch...this area is a massive pain due to the complexity of the DAC name stuff.

ryanmolden added a commit to ryanmolden/clrmd that referenced this issue Jul 26, 2023
@ryanmolden
Fix bugs in DAC names that either contain non-closed generics or non-…
c0ba6f4 
…assembly qualified names (see bug microsoft#897)

Add lots of comments to parser as its complex due to having to deal with tragedies like the type name in ParseGenericWithComplexGenericArgs2

Replace uses of char literals in numerous places with their named constants I was using elsewhere

Correct numerous comment spelling errors (thanks VS spell checker)

Add numerous tests both for the case in 897, some variants of it, and another case I encountered internally
@ryanmolden ryanmolden mentioned this issue Jul 26, 2023
Merged
leculver pushed a commit to ryanmolden/clrmd that referenced this issue Aug 22, 2023
@ryanmolden @leculver
Fix bugs in DAC names that either contain non-closed generics or non-…
808424c 
…assembly qualified names (see bug microsoft#897)

Add lots of comments to parser as its complex due to having to deal with tragedies like the type name in ParseGenericWithComplexGenericArgs2

Replace uses of char literals in numerous places with their named constants I was using elsewhere

Correct numerous comment spelling errors (thanks VS spell checker)

Add numerous tests both for the case in 897, some variants of it, and another case I encountered internally
leculver added a commit that referenced this issue Aug 22, 2023
@ryanmolden @leculver
Fix bugs in DAC names that either contain non-closed generics or non-…
d6684cc 
…assembly qualified names (#1172)

* Fix bugs in DAC names that either contain non-closed generics or non-assembly qualified names (see bug #897)

Add lots of comments to parser as its complex due to having to deal with tragedies like the type name in ParseGenericWithComplexGenericArgs2

Replace uses of char literals in numerous places with their named constants I was using elsewhere

Correct numerous comment spelling errors (thanks VS spell checker)

Add numerous tests both for the case in 897, some variants of it, and another case I encountered internally

* More DAC name corner cases

* Add accidental omission of nullability specifier

* Fix spacing complaints in my if statements

* Fix typos/omitted words in comment in test

* Fix copy paste error where I left Fact off of  couple of test methods

* Reduce allocations

---------

Co-authored-by: Lee Culver <leculver@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ryanmolden @leculver @catstrike