Bug 22893 - Linking fails with MT2001: System.NullReferenceException at Mono.Cecil.Mixin.GetNestedType
Summary: Linking fails with MT2001: System.NullReferenceException at Mono.Cecil.Mixin....
Status: VERIFIED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 7.4.x
Hardware: PC Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Sebastien Pouliot
URL:
: 22963 23232 ()
Depends on:
Blocks:
 
Reported: 2014-09-11 19:07 UTC by Kent Green [MSFT]
Modified: 2014-11-10 09:10 UTC (History)
13 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Logfiles from the error (524.45 KB, application/zip)
2014-09-11 19:07 UTC, Kent Green [MSFT]
Details
Minimized test case (20.42 KB, application/zip)
2014-09-11 19:34 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details
Diagnostic, verbose build output (61.84 KB, text/plain)
2014-09-11 21:02 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details
PortableLib.dll from Windows (6.50 KB, application/x-msdownload)
2014-09-11 22:29 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
VERIFIED FIXED

Description Kent Green [MSFT] 2014-09-11 19:07:00 UTC
Created attachment 8007 [details]
Logfiles from the error

Overview:
Linker error MT2001: Object reference not set to an instance of an object at
Mono.Cecil.Mixin.GetNestedType.

Steps to reproduce:
Will be described in a private comment with the test case demonstrating the
issue is from a customer's app.

From priority case:
https://xamarin.desk.com/agent/case/88323

gist of full stack trace:
https://gist.github.com/brendanzagaeski/fb83c90cf12272d4905c

Build information:
=== Xamarin Studio ===

Version 5.4 (build 216)
Installation UUID: 8ef63a7c-1b18-40de-a334-7f78777fcb55
Runtime:
    Mono 3.8.0 ((no/45d0ba1)
    GTK+ 2.24.23 (Raleigh theme)

    Package version: 308000009

=== Apple Developer Tools ===

Xcode 5.1.1 (5085)
Build 5B1008

=== Xamarin.iOS ===

Version: 8.0.0.9 (Business Edition)
Hash: 436246d
Branch: 
Build date: 2014-09-10 00:04:26-0400

=== Xamarin.Mac ===

Version: 1.10.0.10 (Business Edition)

=== Xamarin.Android ===

Version: 4.16.0 (Business Edition)
Android SDK: /Users/kentgreen/Library/Developer/Xamarin/android-sdk-macosx
    Supported Android versions:
        2.1   (API level 7)
        2.2   (API level 8)
        2.3   (API level 10)
        3.1   (API level 12)
        4.0   (API level 14)
        4.0.3 (API level 15)
        4.4   (API level 19)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)

=== Build Information ===

Release ID: 504000216
Git revision: bf73535e350da9a84b6990c72149b84467757c52
Build date: 2014-09-09 15:40:19-04
Xamarin addins: cb699c7d52f13def4e9746f8086e9f24ef6d894f

=== Operating System ===

Mac OS X 10.9.4
Darwin Kents-MacBook-Pro.local 13.3.0 Darwin Kernel Version 13.3.0
    Tue Jun  3 21:27:35 PDT 2014
    root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64

---Additional notes---
This bug affects both Android and iOS so I was asked to file a separate report for each. Here is the Android version:
https://bugzilla.xamarin.com/show_bug.cgi?id=22892
Comment 1 Brendan Zagaeski (Xamarin Team, assistant) 2014-09-11 19:34:50 UTC
Created attachment 8008 [details]
Minimized test case

## Steps to reproduce

Attempt to build either the Android app or the iPhone app with the linker mode set to "Link SDK assemblies only".


## Result

Top of the stack trace:
 
> error MT2001: Could not link assemblies. Reason: Object reference not set to an instance of an object
> --- inner exception
> System.NullReferenceException: Object reference not set to an instance of an object
>   at Mono.Cecil.Mixin.GetNestedType (Mono.Cecil.TypeDefinition self, System.String name) [0x00000] in <filename unknown>:0 
>   at Mono.Cecil.TypeParser.TryGetDefinition (Mono.Cecil.ModuleDefinition module, Mono.Cecil.Type type_info, Mono.Cecil.TypeReference& type) [0x00000] in <filename unknown>:0 
>   at Mono.Cecil.TypeParser.GetTypeReference (Mono.Cecil.ModuleDefinition module, Mono.Cecil.Type type_info) [0x00000] in <filename unknown>:0 
>   at Mono.Cecil.TypeParser.ParseType (Mono.Cecil.ModuleDefinition module, System.String fullname) [0x00000] in <filename unknown>:0 
>   at Mono.Cecil.SignatureReader.ReadTypeReference () [0x00000] in <filename unknown>:0 


## Additional information

The 2 app projects are just the default template projects. The PCL project contains just the following code:

public async Task<T> GetAsync<T>(string url) where T : new()
{
    return await Task.Factory.StartNew(async () =>
    {
        var client = new HttpClient();
        var response = await client.GetStringAsync(url);
        return (T)new object();
    }).Unwrap();
}


Commenting out the `var response = await client.GetStringAsync(url);` line stops the problem.
Comment 2 Sebastien Pouliot 2014-09-11 20:53:12 UTC
@Brendan the attached test case (iPhoneApp1) builds fine for me.

Please always provide a the full build log, i.e. not just the exception / stack trace, with extra verbosity (-v -v -v -v) so we have some clues about what happened prior to the error(s).
Comment 3 Brendan Zagaeski (Xamarin Team, assistant) 2014-09-11 21:02:27 UTC
Created attachment 8011 [details]
Diagnostic, verbose build output

It looks like this might somehow be a Mono compiler bug. I cannot reproduce it if I compile the same project via XamarinVS 3.5.57 + Xamarin.iOS 7.4.0.108.


Xamarin.iOS 7.4.0.108 (Hash: 77efa3f)
Mono 3.8.0 ((no/45d0ba1)

Xamarin Studio 5.3 (build 441)
Git revision: befb6aa1176d37a5f678f4274f340a0159091b7a
Xamarin addins: 6dc7c388e31fdfc8014689839d37de0d4622435c

Xcode 5.1 (5084), Build 5B130a
Mac OS X 10.9.4
Comment 4 Brendan Zagaeski (Xamarin Team, assistant) 2014-09-11 21:03:06 UTC
Verbose build logs attached -> NEW
Comment 5 Sebastien Pouliot 2014-09-11 21:26:04 UTC
> It looks like this might somehow be a Mono compiler bug.

Yup, that's exactly what crossed my mind (and why I asked for the build logs). 

It was working fine for me, but this Mac was still using Mono 3.6. After updating to Mono 3.8 I get the same exception (once the PCL was rebuilt).
Comment 6 Sebastien Pouliot 2014-09-11 21:27:48 UTC
And guess that XS shows when decompiling it ?

Decompilation failed: 
System.NullReferenceException: Object reference not set to an instance of an object
  at Mono.Cecil.Mixin.GetNestedType (Mono.Cecil.TypeDefinition self, System.String name) [0x00002] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/TypeDefinition.cs:504 
  at Mono.Cecil.TypeParser.TryGetDefinition (Mono.Cecil.ModuleDefinition module, Mono.Cecil.Type type_info, Mono.Cecil.TypeReference& type) [0x0004f] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/TypeParser.cs:422 
  at Mono.Cecil.TypeParser.GetTypeReference (Mono.Cecil.ModuleDefinition module, Mono.Cecil.Type type_info) [0x00005] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/TypeParser.cs:285 
  at Mono.Cecil.TypeParser.ParseType (Mono.Cecil.ModuleDefinition module, System.String fullname) [0x0001d] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/TypeParser.cs:279 
  at Mono.Cecil.SignatureReader.ReadTypeReference () [0x00012] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/AssemblyReader.cs:3052 
  at Mono.Cecil.SignatureReader.ReadCustomAttributeElementValue (Mono.Cecil.TypeReference type) [0x0003d] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/AssemblyReader.cs:2958 
  at Mono.Cecil.SignatureReader.ReadCustomAttributeElement (Mono.Cecil.TypeReference type) [0x00044] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/AssemblyReader.cs:2946 
  at Mono.Cecil.SignatureReader.ReadCustomAttributeFixedArgument (Mono.Cecil.TypeReference type) [0x00020] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/AssemblyReader.cs:2880 
  at Mono.Cecil.SignatureReader.ReadCustomAttributeConstructorArguments (Mono.Cecil.CustomAttribute attribute, Mono.Collections.Generic.Collection`1 parameters) [0x00039] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/AssemblyReader.cs:2872 
  at Mono.Cecil.MetadataReader.ReadCustomAttributeSignature (Mono.Cecil.CustomAttribute attribute) [0x0004a] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/AssemblyReader.cs:2382 
  at Mono.Cecil.CustomAttribute.<Resolve>m__1 (Mono.Cecil.CustomAttribute attribute, Mono.Cecil.MetadataReader reader) [0x00003] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/CustomAttribute.cs:204 
  at Mono.Cecil.ModuleDefinition.Read[CustomAttribute,CustomAttribute] (Mono.Cecil.CustomAttribute item, System.Func`3 read) [0x00021] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/ModuleDefinition.cs:818 
  at Mono.Cecil.CustomAttribute.Resolve () [0x00030] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/CustomAttribute.cs:203 
  at Mono.Cecil.CustomAttribute.get_HasConstructorArguments () [0x00002] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/external/cecil/Mono.Cecil/CustomAttribute.cs:112 
  at ICSharpCode.Decompiler.Ast.AstBuilder.ConvertCustomAttributes (ICSharpCode.NRefactory.CSharp.AstNode attributedNode, ICustomAttributeProvider customAttributeProvider, System.String attributeTarget) [0x001db] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/contrib/ICSharpCode.Decompiler/Ast/AstBuilder.cs:1399 
  at ICSharpCode.Decompiler.Ast.AstBuilder.ConvertAttributes (ICSharpCode.NRefactory.CSharp.EntityDeclaration attributedNode, Mono.Cecil.MethodDefinition methodDefinition) [0x00004] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/contrib/ICSharpCode.Decompiler/Ast/AstBuilder.cs:1176 
  at ICSharpCode.Decompiler.Ast.AstBuilder.CreateMethod (Mono.Cecil.MethodDefinition methodDef) [0x00146] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/contrib/ICSharpCode.Decompiler/Ast/AstBuilder.cs:796 
  at ICSharpCode.Decompiler.Ast.AstBuilder.AddTypeMembers (ICSharpCode.NRefactory.CSharp.TypeDeclaration astType, Mono.Cecil.TypeDefinition typeDef) [0x001e0] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/contrib/ICSharpCode.Decompiler/Ast/AstBuilder.cs:768 
  at ICSharpCode.Decompiler.Ast.AstBuilder.CreateType (Mono.Cecil.TypeDefinition typeDef) [0x00412] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/contrib/ICSharpCode.Decompiler/Ast/AstBuilder.cs:375 
  at ICSharpCode.Decompiler.Ast.AstBuilder.AddTypeMembers (ICSharpCode.NRefactory.CSharp.TypeDeclaration astType, Mono.Cecil.TypeDefinition typeDef) [0x00039] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/contrib/ICSharpCode.Decompiler/Ast/AstBuilder.cs:740 
  at ICSharpCode.Decompiler.Ast.AstBuilder.CreateType (Mono.Cecil.TypeDefinition typeDef) [0x00412] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/contrib/ICSharpCode.Decompiler/Ast/AstBuilder.cs:375 
  at ICSharpCode.Decompiler.Ast.AstBuilder.AddType (Mono.Cecil.TypeDefinition typeDef) [0x00003] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/contrib/ICSharpCode.Decompiler/Ast/AstBuilder.cs:264 
  at MonoDevelop.AssemblyBrowser.DomTypeNodeBuilder+<Decompile>c__AnonStorey2.<>m__0 (ICSharpCode.Decompiler.Ast.AstBuilder builder) [0x00008] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/src/addins/MonoDevelop.AssemblyBrowser/MonoDevelop.AssemblyBrowser/TreeNodes/DomTypeNodeBuilder.cs:212 
  at MonoDevelop.AssemblyBrowser.DomMethodNodeBuilder.Decompile (Mono.TextEditor.TextEditorData data, Mono.Cecil.ModuleDefinition module, Mono.Cecil.TypeDefinition currentType, System.Action`1 setData, ICSharpCode.Decompiler.DecompilerSettings settings) [0x00033] in /Users/builder/data/lanes/monodevelop-lion-master/68a2ba48/source/monodevelop/main/src/addins/MonoDevelop.AssemblyBrowser/MonoDevelop.AssemblyBrowser/TreeNodes/DomMethodNodeBuilder.cs:145
Comment 7 Sebastien Pouliot 2014-09-11 22:14:06 UTC
The error occurs when trying to read the custom attribute on:

> System.Threading.Tasks.Task`1<T> PortableLib.Class1/<GetAsync>c__async0`1/<GetAsync>c__AnonStorey5`1::<>m__0()

Getting the nested type in "<GetAsync>c__AnonStorey5" returns null, which cause the NRE when it's used to get last, nested, type "<GetAsync>c__async4"

Now I would have assumed that "<GetAsync>c__AnonStorey5" should have been "<GetAsync>c__AnonStorey5`1" so that might be mis-encoded metadata (from the compiler) or mis-parsed by Cecil.


Note: it worked with Mono 3.6 but (at least XS assembly browser showed it) as [AsyncStateMachine(null)] which was likely wrong (as far as parsing goes).


c.c. Marek as he's likely aware of any such changes between 3.6 and 3.8.


@Brendan could you attach the PortableLib.dll build on Windows (cdc) so I can compare it ? thanks!
Comment 8 Brendan Zagaeski (Xamarin Team, assistant) 2014-09-11 22:29:13 UTC
Created attachment 8012 [details]
PortableLib.dll from Windows

Here's the PortableLib.dll as compiled by csc (via Visual Studio) on Windows.
Comment 9 Sebastien Pouliot 2014-09-12 00:00:27 UTC
Thanks! it seems the [AsyncStateMachine] is not even used in that binary, generated code is pretty different. In any case the lack of the attribute (pointed to deeply nested types) explains why that works.
Comment 10 Prashant manu 2014-09-12 02:32:45 UTC
*** Bug 22892 has been marked as a duplicate of this bug. ***
Comment 11 Marek Safar 2014-09-12 09:21:05 UTC
This is mcs bug. It's not necessary regression as 3.6 has attribute value encoding broken for this attribute.

In this case nested compiler generated type is using extra `1 which is wrong (it has been like that for some time, perhaps year) and this has been fixed in master
Comment 12 Sebastien Pouliot 2014-09-12 09:32:43 UTC
@Marek it's a regression since it means every released XI will choke on the badly encoded attribute. IOW even if I ignore this (in 8.x+) it will still be broken for lots of people (across XI, XM and XA).

Q: Is that fixed in 3.10 ?

Q: Can it be backported to 3.8 ?

In both cases it would minimize the "life" of this issue in the wild (so less chance to produce bad binaries in the component store / nuget...)
Comment 13 Marek Safar 2014-09-12 09:40:05 UTC
It's fixed in master only (pushed the fix few minutes ago) but it should be safe to backport.

I wrote that it's not necessary regression as this issue exists in most versions before 3.8 but it's not easy to trigger
Comment 14 Sebastien Pouliot 2014-09-12 09:45:46 UTC
Heh, it's not a regression since it was broken before, I get that :-). OTOH it's now broken differently and that affect customers (so they are/will be suffering a regression).

@Miguel it might be easier* to update Mono 3.8 (and 3.10) with that fix than to re-release every active XI, XM and XA branches (since it would require a mono bump anyway).

* ignoring this (in Cecil / linker) is possible but that might hide future problems down the road...
Comment 15 Marek Safar 2014-09-12 10:02:24 UTC
I don't think XI, XA are affected. We don't have much async code there and it requires special code block to trigger it.
Comment 16 Sebastien Pouliot 2014-09-12 10:14:09 UTC
> I don't think XI, XA are affected.

That depends on how you interpret this. The customer that reported this to support (which created bugs for XI and XA) would likely disagree with you ;-)

OTOH I agree that, from our point of view, the binaries we ship are likely not affected (and we do not need to re-release them) since we unit test* most of assemblies (and the linker is enabled on QA bots running tests on devices*). IOW if we had such a badly encoded attribute we would have got the same NRE

The best solution is to re-release a new Mono 3.8 with this fix (hopefully there won't be too many bad binaries in the wild).

* at least for XI (and XA kind of inherit those as well)
Comment 17 Miguel de Icaza [MSFT] 2014-09-12 10:14:47 UTC
I agree, we should update Mono 3.8 and Mono 3.10 with the fix.

Marek, can you backport the fixes to those branches?
Comment 18 Sebastien Pouliot 2014-09-12 11:13:58 UTC
Marek backported the fix to 3.8 (and 3.10) in mono-3.8.0-branch db71bc145b655e57e8f5529b23da37ccb933b4c2

QA: this needs to be verify using 7.4 (stable) and the mono 3.8.x version that includes the above commit.
Comment 19 Sebastien Pouliot 2014-09-13 13:49:41 UTC
*** Bug 22963 has been marked as a duplicate of this bug. ***
Comment 20 Sebastien Pouliot 2014-09-22 09:19:22 UTC
*** Bug 23232 has been marked as a duplicate of this bug. ***
Comment 22 Mohit Kheterpal 2014-09-24 11:26:54 UTC
I have checked this Issue and now I am able to build attached application successfully with latest Mono when Linker option is set to 'Link SDK Assemblies only'. This is the build output for the same for iOS: https://gist.github.com/saurabh360/2c6d9b3a727a397b689a
AND for Android: https://gist.github.com/saurabh360/9c5b4f0a6432585ab61f

X.S 5.4 (Build 241)
Git revision: d7682de02218437de17ceeaad94c6ec63239b925
Mono 3.8.0-13
X.iOS 8.0.0.63
X.Android 4.17.0-10
Comment 23 Sebastien Pouliot 2014-10-30 17:42:17 UTC
*** Bug 24172 has been marked as a duplicate of this bug. ***
Comment 24 Sebastien Pouliot 2014-11-10 09:10:06 UTC
*** Bug 24172 has been marked as a duplicate of this bug. ***