dotnet / android

.NET for Android provides open-source bindings of the Android SDK for use with .NET managed languages such as C#
MIT License
1.94k stars 533 forks source link

Compiler crashes when building an Android Project (OSX) #1674

Closed fl-eric closed 6 years ago

fl-eric commented 6 years ago

Steps to Reproduce

Either compile the project using Visual Studio for Mac, or msbuild on Terminal.

Android build tools tried: 27.0.3 and 26.0.3. Mono Frameworks tried: 4.8.0 and 4.8.1. (Mono 4 is required to run legacy libraries).

Expected Behavior

Compile and generate .apk file.

Actual Behavior

On Visual Studio for Mac, an alert with "Fatal error" message appears, then it closes automatically (without clicking on OK button of the alert window).

On Terminal the following message appears (full output attached):

Stacktrace:

  at <unknown> <0xffffffff>
  at Xamarin.Tools.Zip.Native.zip_open (string,Xamarin.Tools.Zip.OpenFlags,Xamarin.Tools.Zip.ErrorCode&) [0x00000] in <0733d002219547e7af60b6fb41716161>:0
  at Xamarin.Tools.Zip.ZipArchive.Open (string,Xamarin.Tools.Zip.OpenFlags) [0x00009] in <0733d002219547e7af60b6fb41716161>:0
  at Xamarin.Tools.Zip.ZipArchive.Open (string,System.IO.FileMode,string,bool,Xamarin.Tools.Zip.IPlatformOptions) [0x0005a] in <0733d002219547e7af60b6fb41716161>:0
  at Xamarin.Android.Tools.Files.ReadZipFile (string,bool) [0x00000] in <fdfe8f54615a4e2ab24c72dc90da5c64>:0
  at Xamarin.Android.Tasks.MonoAndroidHelper.IsValidZip (string) [0x00000] in <fdfe8f54615a4e2ab24c72dc90da5c64>:0
  at Xamarin.Android.Tasks.GetAdditionalResourcesFromAssemblies.MakeSureLibraryIsInPlace (string,string,string,string,string) [0x00142] in <fdfe8f54615a4e2ab24c72dc90da5c64>:0
  at Xamarin.Android.Tasks.GetAdditionalResourcesFromAssemblies.AddAttributeValue (System.Collections.Generic.ICollection`1<string>,Mono.Cecil.CustomAttribute,string,string,bool,string) [0x002c6] in <fdfe8f54615a4e2ab24c72dc90da5c64>:0
  at Xamarin.Android.Tasks.GetAdditionalResourcesFromAssemblies/<>c__DisplayClass37_0.<DoExecute>b__1 () [0x001a2] in <fdfe8f54615a4e2ab24c72dc90da5c64>:0
  at System.Threading.Tasks.Task.InnerInvoke () [0x00012] in <f712f98eb8e445c8918edaf595bbe465>:0
  at System.Threading.Tasks.Task.Execute () [0x00016] in <f712f98eb8e445c8918edaf595bbe465>:0
  at System.Threading.Tasks.Task.ExecutionContextCallback (object) [0x00007] in <f712f98eb8e445c8918edaf595bbe465>:0
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x0008d] in <f712f98eb8e445c8918edaf595bbe465>:0
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in <f712f98eb8e445c8918edaf595bbe465>:0
  at System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task&) [0x0005f] in <f712f98eb8e445c8918edaf595bbe465>:0
  at System.Threading.Tasks.Task.ExecuteEntry (bool) [0x0006f] in <f712f98eb8e445c8918edaf595bbe465>:0
  at System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00000] in <f712f98eb8e445c8918edaf595bbe465>:0
  at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00096] in <f712f98eb8e445c8918edaf595bbe465>:0
  at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in <f712f98eb8e445c8918edaf595bbe465>:0
  at (wrapper runtime-invoke) <Module>.runtime_invoke_bool (object,intptr,intptr,intptr) [0x0001e] in <f712f98eb8e445c8918edaf595bbe465>:0

(native stacktrace)

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Version Information

=== Visual Studio Community 2017 for Mac ===

Version 7.5 (build 1254) Installation UUID: 8fbd2e42-6a70-4878-b267-e7b22af25c7f Runtime: Mono 5.10.1.47 (2017-12/8eb8f7d5e74) (64-bit) GTK+ 2.24.23 (Raleigh theme) Xamarin.Mac 4.4.0.36 (master / 0c7c49a6)

Package version: 510010047

=== NuGet ===

Version: 4.3.1.4445

=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet Runtime Versions: 2.0.5 2.0.0 SDK: /usr/local/share/dotnet/sdk/2.1.4/Sdks SDK Versions: 2.1.4 2.0.0 MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/4.8.1/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

Version: 1.6.2 Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 9.3 (14154) Build 9E145

=== Xamarin.Mac ===

Version: 4.4.1.176 (Visual Studio Community)

=== Xamarin.Android ===

Version: 8.3.0.19 (Visual Studio Community) Android SDK: /Users/REDACTED/Library/Developer/Xamarin/android-sdk-macosx 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) 5.0 (API level 21) 5.1 (API level 22) 6.0 (API level 23) 7.0 (API level 24) 7.1 (API level 25) 8.0 (API level 26) 8.1 (API level 27)

SDK Tools Version: 26.1.1 SDK Platform Tools Version: 27.0.1 SDK Build Tools Version: 26.0.3

Java SDK: /usr java version "1.8.0_31" Java(TM) SE Runtime Environment (build 1.8.0_31-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

Android Designer EPL code available here: https://github.com/xamarin/AndroidDesigner.EPL

=== Xamarin.iOS ===

Version: 11.10.1.177 (Visual Studio Community) Hash: 7e782c1e Branch: d15-7 Build date: 2018-04-25 15:27:13-0400

=== Xamarin Inspector ===

Version: 1.4.0 Hash: b3f92f9 Branch: master Build date: Fri, 19 Jan 2018 22:00:34 GMT Client compatibility: 1

=== Build Information ===

Release ID: 705001254 Git revision: 498923ea36d2c7fe440c4e4b8cfb75bd50bbd748 Build date: 2018-05-05 10:35:24-04 Xamarin addins: 219f1c4943b4693b837b4173dd10ea982a47c852 Build lane: monodevelop-lion-d15-7

=== Operating System ===

Mac OS X 10.13.4 Darwin 17.5.0 Darwin Kernel Version 17.5.0 Fri Apr 13 19:32:32 PDT 2018 root:xnu-4570.51.2~1/RELEASE_X86_64 x86_64

=== Enabled user installed addins ===

DeepClean 1.2.2

Log File

Ide.2018-05-10__18-39-17.log.zip

msbuild.output.zip

fl-eric commented 6 years ago

It seems unable to compile Android Class Library projects. I created an empty project of this type and the Visual Studio crashed as well. msbuild also failed with the same exception.

brendanzagaeski commented 6 years ago

Cross-referencing note for the Microsoft team

The same error message has also been reported in: https://developercommunity.visualstudio.com/content/problem/241868/vsfm-75-preview-75-build-1222-crashes-on-launch-tr.html

banshee commented 6 years ago

Just want to add that this has pushed to stable, so right now there are zero shipping versions of Xamarin/Visual Studio for Mac that work at all - not stable, not beta, not alpha, not prealpha. (The prealpha for Xcode 9.4 is also DOA, but from a glance at the logs it's a different problem; reported at https://developercommunity.visualstudio.com/content/problem/252901/visual-studio-2017-for-mac-75-build-1255-crashes-w.html).

fl-eric commented 6 years ago

I fixed this issue downgrading Xamarin.Android. Now I can compile Android Class Libraries again.

These are the commands I ran on OSX terminal:

$ cd /Library/Frameworks/Xamarin.Android.framework/Versions
$ ls
...
8.2.0-15/
8.2.0-16/
8.3.0-19/
Current@ -> 8.3.0-19
$ sudo rm Current
$ sudo ln -s 8.2.0-16 Current
brendanzagaeski commented 6 years ago

Preliminary reproduction attempt notes for the Microsoft team

So far I haven't had luck replicating this error with a combination of a few little template Android class library and application projects. To make a first guess at the cause, maybe the native libzip library (/Library/Frameworks/Xamarin.Android.framework/Versions/8.3.0-19/lib/xamarin.android/xbuild/Xamarin/Android/libzip.3.0.dylib) is not properly handling certain zip files, or perhaps otool -L /Library/Frameworks/Xamarin.Android.framework/Versions/8.3.0-19/lib/xamarin.android/xbuild/Xamarin/Android/libzip.3.0.dylib would indicate a missing system dependency for the library (in affected environments).

fl-eric commented 6 years ago

The same issue was reported here too:

https://developercommunity.visualstudio.com/content/problem/247871/fatal-error-occurs-when-build-xamarinandroid-proje.html

brendanzagaeski commented 6 years ago

Older version links

For other users who might encounter this error and are not yet able to update to building with a current Mono Framework MDK version, if you do not have a previous version of Xamarin.Android in your /Library/Frameworks directory, you can find the previous installer for Xamarin.Android at the bottom of the Xamarin 15.7 Release Blog post.


Follow-up on reproduction attempt notes for the Microsoft team

I was now able to reproduce the issue when using the unsupported older version 4.8.1 of the Mono Framework MDK, as mentioned in the initial description.

My initial attempt at replicating the issue was invalid because I was using the matching recent Mono Framework MDK version 5.10 when building the project. Switching to the use the unsupported combination of the current Xamarin.Android version with the outdated Mono Framework MDK version 4.8.1 did indeed lead to the error. Perhaps this issue is then a limitation of the compatibility of the old Mono Framework MDK version 4.8.1 when running libzip. Since that behavior is already resolved in the current versions of the Mono Framework MDK, I'm not sure if there will be any action to take for this issue.

fl-eric commented 6 years ago

Does it mean that Mono 4.8.1 is not supported anymore? Does it also means that Mono 4.* is already deprecated?

banshee commented 6 years ago

" Since that behavior is already resolved in the current versions of the Mono Framework MDK, I'm not sure if there will be any action to take for this issue."

You can't just crash and not give us any feedback as to why. It's totally OK to say you need to switch, but remember that lots of your users don't even know that's possible - I had to go hunting for where to make that change (and yes, I was set for the older Mono 4.8.0, but I have no idea why, and have no problems switching to the later version).

kylekurz commented 6 years ago

"You can't just crash and not give us any feedback as to why. It's totally OK to say you need to switch, but remember that lots of your users don't even know that's possible - I had to go hunting for where to make that change (and yes, I was set for the older Mono 4.8.0, but I have no idea why, and have no problems switching to the later version)."

+1000 to this. Dying with no user feedback is unacceptable.

brendanzagaeski commented 6 years ago

It could be useful to have a feature that would warn users when building with a down-level version of the Mono Framework MDK. I will aim to file an issue for that shortly.

Note that the default update scenario for users who have never customized the Active Runtime setting in Visual Studio for Mac is that each new installed Mono Framework MDK update will set Visual Studio for Mac to use that latest version. So as far as I know, this exact scenario (a problem when building with a down-level Mono Framework MDK) simply has never come up before. (And the Active Runtime setting in Visual Studio for Mac dates back to 2009 in the open source MonoDevelop history, way back when Novell was the chaperone of the project.)

fl-eric commented 6 years ago

Is it possible to define the Xamarin.Android version to be used in the csproj file? I have projects that uses Mono 5 with the most recent version of Xamarin.Android, and I have projects that requires Mono 4 plus older versios of Xamarin.Android. It wouldn't be nice to have to switch versions manually in the console.

banshee commented 6 years ago

I believe you about the updates changing the default if you haven't changed it, but I suspect you might be overestimating how useful that is. I think I needed to change it a year ago (?) for a Forms project that wouldn't build with the latest one. Never knew about it before that, and had totally forgotten about it seconds after I did it. And I was complaining about monotouch build issues back when all this stuff was still part of Novell, too :-) https://bugzilla.novell.com/show_bug.cgi?id=577984

brendanzagaeski commented 6 years ago

As an additional cross-reference that is actually probably more relevant than the idea of a down-level warning message for the concern of "just crash and not give us any feedback," the fact that Visual Studio for Mac crashes in this scenario rather than just logging the exception and continuing to run is its own separate bug. That issue has a candidate fix that will be included in an upcoming release (one of the upcoming Visual Studio for Mac version 7.6 Preview releases). In my local testing with the latest internal development builds, Visual Studio for Mac does indeed no longer crash in this case, despite the exception in Xamarin.Tools.Zip.Native.zip_open ().

brendanzagaeski commented 6 years ago

That issue has a candidate fix that will be included in an upcoming release (one of the upcoming Visual Studio for Mac version 7.6 Preview releases).

Follow-up: The fix for the Visual Studio for Mac crash will also be included in the upcoming Visual Studio for Mac version 7.5.1 Servicing Update. The Xamarin.Anroid version 8.3 build process still fails when using the old Mono Framework MDK version 4.8 as the Active Runtime, but Visual Studio for Mac will now log the exception and keep running.

kylekurz commented 6 years ago

@brendanzagaeski when you say "log the exception and keep running", does that include a notification to the user? Something needs to explain why the build will eventually fail, assuming VS can detect the problem (which it sounds like the proposed fix is capable of determining).

brendanzagaeski commented 6 years ago

does that include a notification to the user

If I follow the steps from the initial description on this issue to load a solution successfully and then start a build, the new Visual Studio for Mac versions no longer crash but instead show an error in the Errors pad that MSbuild has failed. The build output and Errors pad messages do not mention the full zip_open () exception, but that exception is logged successfully into the Ide.log file. Capturing the standard error stream of the msbuild process to surface the exception in the build output pane as well might be a nice future enhancement.

The new Visual Studio for Mac version 7.5.1.22 Servicing Update has just now been published in the Stable updater channel with the candidate fix for the crash part of this issue. If you try that version and see that it does not produce the kind of feedback you would like to see for your scenario, please do Report a Problem for Visual Studio for Mac to request further future enhancements. Thanks in advance!

banshee commented 6 years ago

Great, I'll try it immediately. Although I hope it's not the same code as the prealpha for Xcode 9.4, since that's yet another Xamarin release that can't build our code https://developercommunity.visualstudio.com/content/problem/253944/cant-compile-android-project-get-error-msb4018-the.html

banshee commented 6 years ago

Note that if you follow the instructions in my original bug, you (hopefully) never would have released to stable, since it can't build. There are a bunch of copies of our code in various bug repos (since you break us constantly), probably the latest is https://developercommunity.visualstudio.com/content/problem/253944/cant-compile-android-project-get-error-msb4018-the.html .

brendanzagaeski commented 6 years ago

Follow-up about workarounds for mixed Xamarin.Android versions

Is it possible to define the Xamarin.Android version to be used in the csproj file?

@fl-eric, I took quick first non-engineering team look at this. I did not find an MSBuild property to control that in my initial skim, but (a) there might still be one, and (b) even if there isn't, there might be another way to adjust the version per-project.

In the mean time, in case it's helpful, I found out (from my investigation below) that it is possible to work around this issue by moving the current libZipSharp.dll assembly to a backup location and copying the previous version from Xamarin.Android 8.2 into Xamarin.Android 8.3. For example, you can run commands similar to the following in a Terminal.app command prompt:

sudo mv -n /Library/Frameworks/Xamarin.Android.framework/Versions/8.3.0-19/lib/xbuild/Xamarin/Android/libZipSharp.dll  "$HOME/Desktop/"
sudo cp -an /Library/Frameworks/Xamarin.Android.framework/Versions/8.2.0-16/lib/xbuild/Xamarin/Android/libZipSharp.dll /Library/Frameworks/Xamarin.Android.framework/Versions/8.3.0-19/lib/xbuild/Xamarin/Android/

The difference between the 2 assemblies is just one IL instruction due to a newer version of the Roslyn C# compiler. That change does not affect how the library is used by Xamarin.Android, so the previous version would work fine for now.

Investigation notes for the exception in Xamarin.Tools.Zip.Native.zip_open ()

To assist the engineering team, I picked up on some investigation of the exception in Xamarin.Tools.Zip.Native.zip_open (). It turns out that the change in behavior happens because the LibZipSharp bundled in Xamarin.Android version 8.3 was built using the Roslyn version 2.6 C# compiler, while the LibZipSharp bundled in Xamarin.Android version 8.2 was built using the Roslyn version 2.3 C# compiler. The Roslyn version 2.6 C# compiler started using the conv.u IL instruction in a new context (not specific to the LibZipSharp library), and this required a corresponding change in the Mono runtime. That change is available in Mono Framework MDK version 5.8 and higher (https://github.com/mono/mono/pull/6020).

So there isn't any bug follow-up bug for Xamarin.Android or the Mono Framework MDK to fix at this time for the Xamarin.Tools.Zip.Native.zip_open () exception.

Follow-up about IDE warnings for down-level Mono Framework MDK versions

It could be useful to have a feature that would warn users when building with a down-level version of the Mono Framework MDK. I will aim to file an issue for that shortly.

I have now Reported a Problem to request warnings for the scenario of using an unexpected Active Runtime setting: https://developercommunity.visualstudio.com/content/problem/254230/visual-studio-for-mac-does-not-show-any-warnings-w.html.

valdetero commented 6 years ago

I have this issue too. My scenario is that I specifically wanted mono v4.8.1. I started the project 2+ years ago and it's on the app stores. I'm using an older version of Fody (and plugins) that aren't updated to work with Mono 5. I would have to manually recreate the functionality that isn't updated. I have one build machine and I need it updated to build the latest version of new apps, but I obviously need it to work with this legacy app.

@brendanzagaeski Is there some command-line argument or some build step that I can run to "pin" the Xamarin.Android / libZipSharp version in my build? I'm using VSTS with an on-prem Mac mini. I have the older versions of Xamarin.Android still on the machine. I would prefer not to move the files / downgrade Xamarin.Android during a build because if anything got messed up it could affect the builds for other apps.

brendanzagaeski commented 6 years ago

Is there some command-line argument or some build step that I can run to "pin" the Xamarin.Android / libZipSharp version in my build?

I'm not aware of anything, but in theory there shouldn't be a problem with overwriting the libZipSharp.dll assembly in Xamarin.Android version 8.3 with the old version from Xamarin.Android version 8.2 (see the steps near the top of my previous comment). If by chance you automatically reformat and re-provision your Mac mini each day (or similar), you could add a step to overwrite the libZipSharp.dll assembly with the old version during that process. Or if you keep the system mostly unchanged from day to day, then you could just overwrite the assembly by hand once. Then you would be able to use Xamarin.Android version 8.3 with either Mono Framework MDK version 4.8 or version 5.10, so you would in theory be able to build both your old projects and your new projects.

brendanzagaeski commented 6 years ago

Coming back through to this issue to tidy up, I'll close it now that two of the core problems (Visual Studio for Mac crashing rather than handling the exception gracefully and Mono Framework MDK not handling the conv.u IL instruction) are resolved and now that there is a separate item to track future improvements for the Active Runtime setting. Thanks once more for the report!