Bug 25344 - Mono CIL Stripper error on Index is less than 0 or more than or equal to the list count.
Summary: Mono CIL Stripper error on Index is less than 0 or more than or equal to the ...
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: General (show other bugs)
Version: 3.9
Hardware: PC Mac OS
: High normal
Target Milestone: ---
Assignee: Bugzilla
Depends on: 31009
  Show dependency tree
Reported: 2014-12-12 13:10 UTC by Prashant Cholachagudda
Modified: 2015-10-20 01:40 UTC (History)
11 users (show)

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

Thoroughly minimized test case (21.59 KB, application/zip)
2015-04-01 00:31 UTC, Brendan Zagaeski (Xamarin Support)

Description Prashant Cholachagudda 2014-12-12 13:10:03 UTC
The build error happens on mtbs only when linking is enabled (Link SDK Only). 
An exception occurs at link time on the MTBS side and the connection to the build machine from VS is closed without any error messages. We don't see any build error if linker is disabled.

 # Version Information

## Windows Box
VS 2013 update 4
Xamarin for Visual Studio

## Mac

Sample code and logs in private comment.
Comment 2 Sunil Kumar 2014-12-30 12:11:24 UTC
I have tried to reproduce this issue. I downloaded the attached sample project from link given in comment 1. I tried to open this sample project using VS and getting some warning popups, after that if I builds this project then it gives builds errors. Here is the screencast for the same: 

Please let me know how can I reproduce this issue.

Environment info:
Microsoft Visual Studio Professional 2013
Version 12.0.31101.00 Update 4
Microsoft .NET Framework
Version 4.5.50938

Xamarin (10cfd178d55287f09c85f5a1e604dfe20889a40f)
Xamarin.Android (ba9bbbdd44cfdc4bf485e8885bd2ad24fba525f7)
Xamarin.iOS (840a925103a0bf4a856507f13d5eaee3c1579c2f)
Comment 3 Guillaume 2014-12-30 13:36:49 UTC
The errors you seen only appears on the first build, rebuilding the solution clean them. We have never figured out why...

The reproduce the issue, you have to:
     - Set the project Distech.X50.UI.Touch as the startup project
     - Select the build config Release/iPhone
     - Choose a valid development device
     - Change the signing identity in project settings to Automatic (it has been forced due to an issue fixed since due to Apple provisioning profile renaming and is no longer required)
     - Start a debug session

I also made a screencast of how to reproduce: http://screencast.com/t/UwtGfaR3nyJD

As a side note, even if the issue is reproduced in this screencast with an MTBS running in a VM, our build server which use an MTBS running on a Mac Mini is impacted by the same effect.
Comment 4 Prashant Cholachagudda 2015-01-16 10:00:05 UTC
Steps to reproduce in Comment #3
Comment 5 Brendan Zagaeski (Xamarin Support) 2015-01-30 13:23:18 UTC
Thanks for the extra details! I was able to reproduce the problem following the steps in comment 3.

I'll add a little note here to surface the error message that appears in the project build log on the build host (~/Library/Logs/Xamarin/MonoTouchVS/*UITouch*.log):

> Stripping assembly /Users/admin/Library/Caches/Xamarin/mtbs/builds/UITouch/aa623b68d1bca03f0a501ebee0543689/obj/iPhone/Release/mtouch-cache/Build/Cirrious.MvvmCross.Binding.dll
> /Library/Frameworks/Mono.framework/Versions/Current/bin/mono
>   /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/4.5/mono-cil-strip.exe
>   /Users/admin/Library/Caches/Xamarin/mtbs/builds/UITouch/aa623b68d1bca03f0a501ebee0543689/obj/iPhone/Release/mtouch-cache/Build/Cirrious.MvvmCross.Binding.dll
>   bin/iPhone/Release/UITouch.app/Cirrious.MvvmCross.Binding.dll
> Mono CIL Stripper
> Error: System.ArgumentOutOfRangeException: Index is less than 0 or more than or equal to the list count.
> Parameter name: index

## Corresponding error from the diagnostic build output (`buildLog.txt`)

>   Executing task: Xamarin.iOS.Tasks.MTouchTask (TaskId:954)
>   Server returned an error. The underlying connection was closed: The connection was closed unexpectedly.
>    (TaskId:954)
>   Remote task execution failed. (TaskId:954)
>   MTouchTask: 2014-12-01T10:39:37.5981734-05:00 - Finished (TaskId:954)

## There doesn't appear to be any corresponding error in `mtbserver.log`

## My version info

### Windows 8.1 64-bit, in VMWare Fusion 6.0.5 (2209127)
Microsoft Visual Studio Professional 2013
Version 12.0.30723.00 Update 3
Microsoft .NET Framework
Version 4.5.51641

Xamarin (39a70ae)
Xamarin.Android (49a04b966feb40dfdba49d57ba16249b66d606a6)
Xamarin.iOS (3b3ef438017c7ecf486defa9e01567a5f2b3cb2a)

### OS X 10.9.5, MacBook Air

Xamarin.iOS (Business Edition)
Hash: 3b3ef43
Build date: 2015-01-24 09:42:21-0500

Xcode 6.1 (6604), Build 6A1052d
Comment 7 Brendan Zagaeski (Xamarin Support) 2015-04-01 00:31:26 UTC
Created attachment 10580 [details]
Thoroughly minimized test case

I was able to recreate the problem from scratch in a new project. The new test case contains 2 projects: an iOS app project and a VB.NET PCL project.

(Note for future reference for any customers who happen to read this bug: minimizing the test case will often accelerate the bug fixing process or reveal workarounds during the minimization process.)

## Workaround?

It seems that the failure during `mono-cil-strip` is non-fatal? If you change the "Additional mtouch arguments" in this new test case (or in the original test case) so that that field contains just one "-v" (or is empty), the `mono-cil-strip` command will still fail, but the project will build successfully.

The original test app built and launched successfully in the iPhone|Release configuration after I removed the "Additional mtouch arguments".

(Beware of bug 26308 when adjusting this setting via the project properties. You'll need to manually re-select "Link SDK assemblies only" each time you open the properties to ensure the correct linker setting is maintained.)

## New test case

- The iOS app project references the VB.NET PCL project, and just instantiates the 1 class contained in the VB.NET PCL project: `var x = new VBClassLibrary1.Class1();`

- The VB.NET PCL project contains 1 tiny class:
> Public Class Class1
>     Dim X = System.Net.DecompressionMethods.Deflate
>     Dim Y As System.Net.IWebProxy
>     Dim Z As System.Net.TransportContext
> End Class

## Additional discussion

I found that the assembly that fails during stripping is actually `System.Net.Http.Primitives.dll`:

> /Library/Frameworks/Mono.framework/Versions/Current/bin/mono
>   /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/4.5/mono-cil-strip.exe
>     /Volumes/Cases/macuser/Library/Caches/Xamarin/mtbs/builds/DistechX50UITouch/16bb8d380a7b277972e5afebc62a34be/obj/iPhone/Release/mtouch-cache/Build/System.Net.Http.Primitives.dll
>     /Volumes/Cases/macuser/Library/Caches/Xamarin/mtbs/builds/DistechX50UITouch/16bb8d380a7b277972e5afebc62a34be/bin/iPhone/Release/DistechX50UITouch.app/System.Net.Http.Primitives.dll''

It seems that the `System.Net.Http.Primitives.dll` that gets copied into the `Build` folder from the `PreBuild` folder is somehow invalid.

The version of `System.Net.Http.Primitives.dll` that's in the "Link" folder [1] (before linking) is roughly 21 KB.

> [1] /Volumes/Cases/macuser/Library/Caches/Xamarin/mtbs/builds/DistechX50UITouch/16bb8d380a7b277972e5afebc62a34be/obj/iPhone/Release/mtouch-cache/Link/System.Net.Http.Primitives.dll

After the linker adjusts this file (to fix up the IL offsets maybe?), it places a new version in the "PreBuild" folder that is only 5 kb.

This all seems a bit curious. `System.Net.Http.Primitives.dll` looks like it might be a facade assembly, so I'm not sure that it's supposed to be in the app bundle at all?
Comment 8 Brendan Zagaeski (Xamarin Support) 2015-04-01 03:56:55 UTC
It is possible to hit the same error using Xamarin Studio on Mac, but it requires a slightly different test case, so I filed a separate bug for that: Bug 28617. Depending on how Bug 28617 ends up getting fixed, it might directly solve this bug too.
Comment 9 Paul Johnson 2015-04-19 06:42:39 UTC
I'm seeing this bug with the current stable release

=== Xamarin Studio ===

Version 5.9 (build 427)
Installation UUID: f3d1a29c-1ba2-4a83-a193-1087efe91a85
	Mono 4.0.0 ((detached/d136b79)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 400000143

=== Xamarin.Android ===

Version: (Business Edition)
Android SDK: /Users/PFJ/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
Java SDK: /usr
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

=== Xamarin Android Player ===

Version: Unknown version
Location: /Applications/Xamarin Android Player.app

=== Apple Developer Tools ===

Xcode 6.3 (7569)
Build 6D570

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: f7736a4
Build date: 2015-04-09 04:22:08-0400

=== Xamarin.Mac ===

Version: (Business Edition)

=== Build Information ===

Release ID: 509000427
Git revision: 04666fd43a57b4782529cad9723ce1f54926fe6c
Build date: 2015-04-14 18:06:43-04
Xamarin addins: 791954691dfbc403676a103e52a0bb9754b9af29

=== Operating System ===

Mac OS X 10.10.4
Darwin Pauls-iMac.local 14.3.0 Darwin Kernel Version 14.3.0
    Wed Apr  8 03:17:44 PDT 2015
    root:xnu-2782.20.48~13/RELEASE_X86_64 x86_64
Comment 10 Paul Johnson 2015-04-19 06:46:49 UTC
adding -v when building for the app store doesn't let it build to create an archive. works fine though for debug
Comment 11 Paul Johnson 2015-04-19 09:47:44 UTC
Reverting to the previous version of mono solves the problem for me (the version of mono touch makes no difference - having it on stable with the alpha version of mono still shows the issue)
Comment 12 Brendan Zagaeski (Xamarin Support) 2015-04-20 19:12:48 UTC
@Paul Johnson, thanks for the report. Based on the symptoms you're describing, I think you might be hitting a closely related but distinct bug. I would recommend filing a separate bug report for the issue you're seeing, being sure to include a zipped up test case that demonstrates that specific problem. Feel free to add a link to this bug (bug 25344) in the new report, and also feel free to add a link to the new report on this page.

## Other updates

The fixes for bug 28617 (as mentioned in comment 8) are included in the current Alpha/Beta versions (XamarinVS 3.11, Xamarin.iOS 8.10, Mono 4.0). Those fixes stop the problem in my minimized test case from comment 7 (see also the "Version information" below). So I suspect this bug is in fact a duplicate of bug 28617.

Unfortunately there is a second (I think unrelated) regression in Xamarin.iOS 8.10 (Bug 29256) exposed by the original full test case (from private comment 1). That second bug is currently blocking me from verifying whether the fix for bug 28617 solves the problem for the original test case. So I will leave this bug (bug 25344) open for now. Once bug 29256 is fixed, I will test the original full test case once more to verify that it builds without error.

## Version information

### Windows 8.1 64-bit, in VMWare Fusion 6.0.5 (2209127)

Microsoft Visual Studio Professional 2013
Version 12.0.30723.00 Update 3

Xamarin   3.11.431.0 (3673cfb)
Xamarin.iOS (7741cc495ab0baf04ff0405d0604bc27f0ecae2e)

### OS X 10.9.5, MacBook Air

Xamarin.iOS, (Business Edition)
Hash: c2c0012
Branch: master
Build date: 2015-04-14 17:26:21-0400

Mono 4.0.0 (detached/d136b79)

Xcode 6.2 (6776), Build 6C131e
Comment 13 Brendan Zagaeski (Xamarin Support) 2015-06-12 15:57:23 UTC
Small update: Bug 29256 is now fixed as of "Cycle 5 – Service Release 2", but it turns out that final verification of the test case from private comment 1 also depends on Bug 31009. I will update this bug again after Bug 31009 is fixed.
Comment 14 Joaquin Jares 2015-10-06 16:13:53 UTC
@Brendan 31009 is now verified -> fixed. Can you retest this? Marking as fixed for retesting.
Comment 15 Brendan Zagaeski (Xamarin Support) 2015-10-20 01:40:26 UTC
## Final verification of the test case from private comment 1. Verified.

I have now verified that the original full test case for this bug builds without error as of "Cycle 5 – Service Release 2" Stable.

As it turned out, the final Stable build of "Cycle 5 – Service Release 2" somehow stopped the particular cause of Bug 31009 in the test case from private comment 1 (I had tested with Alpha or Beta versions in comment 13). The build completes without error in the "Release|iPhone" configuration following the exact steps to reproduce from comment 3.

### Windows 8.1 64-bit, in VMWare Fusion 6.0.6

XamarinVS 3.11.666.0 (ebae43a)

### OS X 10.9.5, MacBook Air

Xamarin.iOS (ef8c2f7)

Mono 4.0.2 (detached/c99aa0c)

Xcode 6.3.2, Build version 6D2105

## Also verified on Cycle 6 RC 0

For good measure, I also checked the test case from private comment 1 on the current Alpha version "Cycle 6 – Release Candidate 0". Again it built without error.

Note You need to log in before you can comment on or make changes to this bug.