Open greenozon opened 4 years ago
Fun fact: ildasm
has the same problem with this assembly.
Looks like a test of that case with generics+inheritance+nested types where the typename explodes exponentially when compiling.
Here's something producing a similar assembly:
class X<A, B, C, D, E>
{
class Y : X<Y, Y, Y, Y, Y>
{
Y.Y.Y.Y.Y.Y.Y.Y y;
}
}
In IL it's not possible to refer to a nested type via a derived class.
A field Y.Y.Y y;
gets compiled to:
private X<X<X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y>.Y, X<X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y>.Y, X<X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y>.Y, X<X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y>.Y, X<X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y, X<A, B, C, D, E>.Y>.Y>.Y y;
With a higher nested level, the typename becomes exponentially bigger -- the 30 MB assembly is so big due to this single type signature. In text form the typename grows to 109 MB!
The issue with the tree view is that we decode the type of the field for the field: Type
tree view label.
This is especially problematic because the tree view uses an "uncached" type system: every mention of X
in the type signature results in the construction of a new MetadataTypeDefinition
instance.
Not sure what we can do here.. everything is working as designed, it's just an extremely unusual assembly.
I think the only good solution is to replace the SRM signature decoder with our own.
Then we'd be able to abort signature decoding if the signature is too huge (with a small limit for the tree view's TS; but no limit for the decompiler itself).
This could also help merge ApplyAttributeTypeVisitor
into the type decoder which could provide some minor performance benefits -- the TS is immutable so modifying the type tree after decoding involves a bunch of extra allocations.
ILSpy version 6.0.0.5836 used
Steps to reproduce
Error message shown
No errors, ILSpy just hangs eating lots of CPU time + increasing memory consumption, once you find that monster node.
No obfuscation/whatsoever, just a clean assembly
err100.zip