Bug 6081 - x86/Release build crashes on VirtualBox-based VM running Android 4.0.3
Summary: x86/Release build crashes on VirtualBox-based VM running Android 4.0.3
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 4.2.x
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Marek Habersack
Depends on:
Reported: 2012-07-11 12:09 UTC by Alek Slater
Modified: 2016-09-21 19:06 UTC (History)
5 users (show)

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

Crashing Project - Hello World (21.87 KB, application/zip)
2012-08-21 08:06 UTC, Alek Slater
Hugely Long ADB Output :D (12.60 KB, text/plain)
2012-08-23 08:44 UTC, Alek Slater
Even More Logging (6.33 KB, text/plain)
2012-08-23 12:02 UTC, Alek Slater
Mini logfile of program startup and crash (1.81 KB, text/plain)
2013-05-14 06:36 UTC, Heiko Schmitt

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:

Description Alek Slater 2012-07-11 12:09:51 UTC
The App crashes as soon as its uploaded, or started:

I/monodroid-gc(  973): environment supports jni NewWeakGlobalRef
W/monodroid-gc(  973): GREF GC Threshold: 46800
E/mono    (  973): 
E/mono    (  973): Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object
E/mono    (  973): at (wrapper dynamic-method) object.fcb335d2-dcb2-4b48-86a1-3920f8c64df5 (intptr,intptr) <0x00000>
E/mono    (  973): at (wrapper native-to-managed) object.fcb335d2-dcb2-4b48-86a1-3920f8c64df5 (intptr,intptr) <0x00033>
E/mono    (  973): 

It works fine in android 2.3 and 4.0 for x86.
Comment 1 Jonathan Pryor 2012-08-20 16:39:58 UTC
Which Mono for Android version?

What's your app do? I'm unable reproduce the crash with the HelloWorld sample; are you?


If HelloWorld works on your emulator, could you attach a minimal test case that crashes at startup?

 - Jon
Comment 2 Alek Slater 2012-08-21 08:06:32 UTC
Created attachment 2384 [details]
Crashing Project - Hello World

Mono for Android:

It's not just my app, its any apps or code. Its also happening with the hello world sample.
For the record, when I said its happening in the x86 devices / emulators, its basically, an x86 virtual machine instance running in virtualbox.
The interesting thing is, I don't experience any issues what so-ever with the same setup when the virtual machine is for android x86 running 2.3, nor 4.0, it's currently only happening with version 4.0.3.

Just to be complete here, this link here shows a good guide to get an x86 version of android running in virtualbox: http://www.buildroid.org/blog/?page_id=121
Comment 3 Jonathan Pryor 2012-08-21 15:33:23 UTC
The real problem is that I didn't properly read the subject of this bug, which is that the app fails to launch if the shared runtime is disabled for Debug builds.


Fixed in 57488e13.

In the meantime, Don't Do That. Why would you want fast deployment enabled with the shared runtime disabled, anyway? I'm not sure I understand that use-case...
Comment 4 Alek Slater 2012-08-21 23:15:06 UTC
Well, the issue isn't so much with Debug builds, but as the subject says, with Release builds.
Surely that's a valid use case?
Comment 5 Jonathan Pryor 2012-08-22 10:43:00 UTC
Release builds are not a valid use case; the Project Options dialog says:

    [ ] Use Fast Deployment (debug mode only)

The "debug mode only" means Debug builds only, not Release builds.

Using Fast Deployment with Release builds is not a supported combination, as it doesn't make sense: the point to Release builds is a unified package that you can (plausibly) provide to Google Play, Amazon Appstore, side-loading via a web-site, etc. "Fast Deployment" means "don't embed assemblies into the .apk, install them separately as part of the IDE install process." This is completely contrary to the "single-file/no dependencies" purpose for Release builds.
Comment 6 Alek Slater 2012-08-22 11:20:48 UTC
Sorry, I probably did not explain correctly. Now as far as I know it, Fast deployment only applies to debug builds, im not talking about Debug builds at all, im referring to Release. If I left the project I uploaded in Debug mode, sorry, for that. 

The issue is, I do a release build for any app, for x86, for android 2.2, it works, android 4.0 it works, but not for android 4.0.3.

w = works
f = fails

                                                 |Android 2.2 | Android 4.0 | Android 4.0.4
shared mono runtime == true   | w               | w                  | w
shared mono runtime == false   | w               | w                 | f

Now correct me if I'm wrong, but what you want to send to google or amazon, or whatever, is the version where shared mono runtime == false, i.e. the app is not using shared mono run time, meaning its all in the same package, right?

This is the problem here, I'm unable to do that for Android 4.0.4.

Now Fast Deployment, is greyed out for Release builds, so I'm assuming It doesn't matter what it is set to for release, it is not used, right? 

For the record I've not ever touched Fast deployment in any of these tests.
Comment 7 Alek Slater 2012-08-22 11:24:58 UTC
Correction: Its not Android 4.0.4 but Android 4.0.3 :)
Comment 8 Jonathan Pryor 2012-08-22 12:08:10 UTC
I feel like I really need to work on my own reading comprehension...

I may have figured it out. It's a "configuration" issue -- your .csproj doesn't provide a <AndroidSupportedAbis/> element for the 'Release|AnyCPU' configuration. The result is that your Release build gets the default ABIs, which is only armeabi.

For example:

    $ unzip -l bin/Release/mono.samples.helloworld-Signed.apk  | grep lib/
      2788712  08-22-12 11:57   lib/armeabi/libmonodroid.so

The result is that when I install a Release build of your app, the `adb logcat` output contains:

> I/ActivityThread( 1710): Pub mono.samples.helloworld.mono.MonoRuntimeProvider.__mono_init__: mono.MonoRuntimeProvider
> D/AndroidRuntime( 1710): Shutting down VM
> W/dalvikvm( 1710): threadid=1: thread exiting with uncaught exception (group=0xb412f180)
> E/AndroidRuntime( 1710): FATAL EXCEPTION: main
> E/AndroidRuntime( 1710): java.lang.UnsatisfiedLinkError: Couldn't load monodroid: findLibrary returned null
> E/AndroidRuntime( 1710):        at java.lang.Runtime.loadLibrary(Runtime.java:365)

The fix (for me) was to add 'x86' to the list of Supported ABIs for your Release configuration, then rebuild + reinstall the app.

What's odd is that your original report didn't include the above logcat output, and the logcat output from your original report can't possibly be generated unless lib/x86/libmonodroid.so is present within the .apk!

So either I'm still unable to reproduce your exact scenario, or something else is going wrong...

Returning to the original report, try this:

    adb shell setprop debug.mono.log all

Then re-run the app, and attach the (hugely long) `adb logcat` output.

Next, where are you getting an Android 4.0.3 x86 image? My Android SDK Manager has:

    Android 4.0.3 (API 15)
        Intel x86 Atom System Image    API=15 Rev=1  Status=Installed

Furthermore, my Android Virtual Device Manager has:

    AVD Name: Android-v15-x86
    Target Name: Android 4.0.3
    Platform: 4.0.3
    API Level: 15
    CPU/ABI: Intel Atom (x86)

That said, when I launch my emulator, I get version 4.0.4, not 4.0.3!

    $ adb -e shell getprop ro.build.version.release

Just so we're on the same page, what's the ro.build.version.release of your emulator?

Finally, this is how I'm building and installing, from the command line on OS X:

    xbuild /t:Install *.csproj /p:Configuration=Release /p:AdbTarget=-e
Comment 9 Alek Slater 2012-08-23 08:44:09 UTC
Created attachment 2397 [details]
Hugely Long ADB Output :D

I've attached the adb output you wanted.

Here's ro.build.version.release of my device:
$ adb -e shell getprop ro.build.version.release

I build and install the project using the "Start program without debugging" button in MonoDevelop.

Next, where are you getting an Android 4.0.3 x86 image? 
Its not an x86 image like you get from Google, I don't use those at all as I've found the standard android emulator way too slow for use.

I'm running a virtual machine instance of android using virtualbox. The thing is, as far as MonoDevelop is concerned, it's like running it on a real device, or as close to the fact, right? My guess is that if you were to run this on a real device, you would get the same behaviour I'm seeing. I'm not able to verify that hypothesis, because I don't actually have a device laying about :P

I got my Android "emulator" image here, using the instructions there, as well as some of my comments on that page:
Comment 10 Jonathan Pryor 2012-08-23 11:10:14 UTC
Regarding the Google image, if you have an Intel CPU you can drastically speed up the emulator by using IntelHAXM:


Thank you for the log output. It certainly suggests that the correct libmonodroid.so is being installed and is executing.

The odd part is this:

> I/monodroid-assembly( 1053): open_from_update_dir: loaded assembly: HelloWorld.dll

That should only be printed if (1) there is an "update dir" (/data/data/your.package.name/flies/.__override__), and (2) the update dir contains HelloWorld.dll, NEITHER of which should be true for Release apps.

Are you sure this is a Release app? This is getting quite confusing...

Thus, two more questions:

(1) What are the contents of your .apk?

> $ unzip -l bin/Release/mono.samples.helloworld-Signed.apk 
> Archive:  bin/Release/mono.samples.helloworld-Signed.apk
>   Length     Date   Time    Name
>  --------    ----   ----    ----
>      1280  08-22-12 11:57   META-INF/MANIFEST.MF
>      1401  08-22-12 11:57   META-INF/ANDROIDD.SF
>       782  08-22-12 11:57   META-INF/ANDROIDD.RSA
>       520  08-22-12 11:55   res/layout/main.xml
>      1992  08-22-12 11:55   AndroidManifest.xml
>      1144  08-22-12 11:55   resources.arsc
>      3966  08-22-12 11:55   res/drawable-hdpi/icon.png
>      1537  08-22-12 11:55   res/drawable-ldpi/icon.png
>      2200  08-22-12 11:55   res/drawable-mdpi/icon.png
>    158644  08-22-12 11:57   classes.dex
>      4096  08-22-12 11:57   assemblies/HelloWorld.dll
>    438784  08-22-12 11:57   assemblies/Mono.Android.dll
>   1275392  08-22-12 11:57   assemblies/mscorlib.dll
>     11776  08-22-12 11:57   assemblies/System.Core.dll
>    354304  08-22-12 11:57   assemblies/System.dll
>    156160  08-22-12 11:57   assemblies/Mono.Security.dll
>   2788712  08-22-12 11:57   lib/armeabi/libmonodroid.so
>   2767184  08-22-12 11:57   lib/armeabi-v7a/libmonodroid.so
>   3273444  08-22-12 11:57   lib/x86/libmonodroid.so
>  --------                   -------
>  11243318                   19 files

Notice that in my output there are lots of assemblies within the Release .apk. Does your .apk contain the assemblies? (I added <AndroidSupportedAbis>armeabi,armeabi-v7a,x86</AndroidSupportedAbis> to my Release|AnyCPU .csproj section, which is why there are three libmonodroid.so files present.)

(2) Let's enable even more logging, then re-run and attach the logcat output ;-)

    adb shell setprop debug.mono.env MONO_LOG_LEVEL=debug

 - Jon
Comment 11 Alek Slater 2012-08-23 12:02:06 UTC
Created attachment 2399 [details]
Even More Logging

Yes, positive I'm still doing a release build. Like I said before, I can do this and it works for 2.2, 4.0 but not 4.0.3, not changing anything at all in the project between builds and doing a clean build in each case.

I've attached even more logging.

Yeah my unzipped apk looks identical to yers:

unzip -l bin/Release/mono.samples.helloworld-Signed.apk 
Archive:  bin/Release/mono.samples.helloworld-Signed.apk
  Length     Date   Time    Name
 --------    ----   ----    ----
     1280  08-23-12 16:54   META-INF/MANIFEST.MF
     1401  08-23-12 16:54   META-INF/ANDROIDD.SF
      782  08-23-12 16:54   META-INF/ANDROIDD.RSA
      520  08-22-12 16:00   res/layout/main.xml
     1992  08-22-12 16:00   AndroidManifest.xml
     1144  08-22-12 16:00   resources.arsc
     3966  08-22-12 16:00   res/drawable-hdpi/icon.png
     1537  08-22-12 16:00   res/drawable-ldpi/icon.png
     2200  08-22-12 16:00   res/drawable-mdpi/icon.png
   158644  08-23-12 13:27   classes.dex
     4096  08-23-12 16:54   assemblies/HelloWorld.dll
   436224  08-23-12 16:54   assemblies/Mono.Android.dll
  1032704  08-23-12 16:54   assemblies/mscorlib.dll
    11776  08-23-12 16:54   assemblies/System.Core.dll
   259072  08-23-12 16:54   assemblies/System.dll
     5120  08-23-12 16:54   assemblies/Mono.Security.dll
  2791968  08-23-12 16:54   lib/armeabi/libmonodroid.so
  2770488  08-23-12 16:54   lib/armeabi-v7a/libmonodroid.so
  3275428  08-23-12 16:54   lib/x86/libmonodroid.so
 --------                   -------
 10760342                   19 files

The APK file looks ok at least, so thats something ;D
Comment 12 Jonathan Pryor 2012-08-23 14:18:37 UTC
This is looking like something I'll need to debug locally; thank you for your assistance.

Unfortunately I can't provide a timeframe on that investigation. In the meantime I would suggest using the accelerated Android emulator.

 - Jon
Comment 13 Alek Slater 2012-08-23 23:06:18 UTC
Thanks Jon ;)
Comment 14 Heiko Schmitt 2013-05-13 13:48:16 UTC
I get the exact same crash on a real x86 Android device.

->Shared Runtime == false -> crash with n_Activate(...)
->Shared Runtime == true  -> works

Both are release builds, only shared runtime checkbox differs.

This only happens on current x86 firmware. Older ones work ok.

Some hints may be:
The latest x86 image has removed some memcopy safeguards (older images checked for source/destination overlaps and corrected them).
Maybe it has something to do with this?

Tested with current "Xamarin.Android   4.6.04000 (03814ac5)".

Did your research lead to anything?
Comment 15 Heiko Schmitt 2013-05-14 06:36:21 UTC
Created attachment 3962 [details]
Mini logfile of program startup and crash

This also happens with current alpha:

Attached logfile for verification.
Comment 16 Marek Habersack 2016-09-21 19:06:31 UTC
I was unable to find VirtualBox Android images for v4.0.3 (the URL in comment 2 no longer works) but I did test it in the Google Android emulator with the 4.0.3 x86 image and the test app works just fine there. As such, I'm closing this bug in hope that it never comes back :)

Tested with monodroid/master, commit ab8f5949bf6f54ce79266ca54fe94045710c0fe6