Is GC Broken (Xamarin.VisualStudio.3.11.445)?

BradCrandallBradCrandall USMember ✭✭
edited May 2015 in Xamarin.Android

I have noticed since using Xamarin.VisualStudio.3.11.445 my app crashes during a full GC. I have tried 3.11.446, and now 3.11.458 and still getting GC crashes. When I use an older versions (e.g. Xamarin.VisualStudio_3.9.533, 3.9.525, 3.9.483, and 3.9.347) everything works fine.

Is anyone else having these issues with the GC with the newer releases or is it just me? Am I stuck from not going forward with the new releases? Is there something else that I am missing or not doing?

05-30 16:39:48.602 D/dalvikvm( 2397): GREF has increased to 1901
05-30 16:39:49.442 D/Mono ( 2397): DllImport attempting to load: '/system/lib/liblog.so'.
05-30 16:39:49.442 D/Mono ( 2397): DllImport loaded library '/system/lib/liblog.so'.
05-30 16:39:49.452 D/Mono ( 2397): DllImport searching in: '/system/lib/liblog.so' ('/system/lib/liblog.so').
05-30 16:39:49.452 D/Mono ( 2397): Searching for '__android_log_print'.
05-30 16:39:49.452 D/Mono ( 2397): Probing '__android_log_print'.
05-30 16:39:49.452 D/Mono ( 2397): Found as '__android_log_print'.
05-30 16:39:49.462 I/monodroid-gc( 2397): 1800 outstanding GREFs. Performing a full GC!
05-30 16:39:49.502 D/dalvikvm( 2397): GC_EXPLICIT freed 2861K, 11% free 25561K/28487K, paused 0ms+2ms
05-30 16:39:49.502 D/Mono ( 2397): GC_OLD_BRIDGE num-objects 1466 num_hash_entries 1670 sccs size 1646 init 0.00ms df1 0.72ms sort 0.23ms dfs2 0.30ms setup-cb 0.26ms free-data 0.20ms links 301/301/282/2 dfs passes 3437/1947
05-30 16:39:49.502 D/Mono ( 2397): GC_MAJOR: (user request) pause 10.30ms, total 10.40ms, bridge 32.10ms major 1248K/384K los 38K/52K
05-30 16:39:49.502 E/mono-rt ( 2397): Stacktrace:
05-30 16:39:49.502 E/mono-rt ( 2397):
05-30 16:39:49.502 E/mono-rt ( 2397):
05-30 16:39:49.502 E/mono-rt ( 2397): Attempting native Android stacktrace:
05-30 16:39:49.502 E/mono-rt ( 2397):
05-30 16:39:49.512 E/mono-rt ( 2397): Could not unwind with libunwind.so: Cannot load library: load_library[1091]: Library '/data/data/com.BlackDogDetective/lib/libunwind.so' not found
05-30 16:39:49.512 E/mono-rt ( 2397): Could not unwind with libcorkscrew.so: Cannot load library: load_library[1091]: Library '/data/data/com.BlackDogDetective/lib/libcorkscrew.so' not found
05-30 16:39:49.512 E/mono-rt ( 2397):
05-30 16:39:49.512 E/mono-rt ( 2397): No options left to get a native stacktrace :-(
05-30 16:39:49.512 E/mono-rt ( 2397):
05-30 16:39:49.512 E/mono-rt ( 2397): =================================================================
05-30 16:39:49.512 E/mono-rt ( 2397): Got a SIGSEGV while executing native code. This usually indicates
05-30 16:39:49.512 E/mono-rt ( 2397): a fatal error in the mono runtime or one of the native libraries
05-30 16:39:49.512 E/mono-rt ( 2397): used by your application.
05-30 16:39:49.512 E/mono-rt ( 2397): =================================================================
05-30 16:39:49.512 E/mono-rt ( 2397):
05-30 16:39:49.512 F/libc ( 2397): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=128)

Answers

  • darrell.tunnelldarrell.tunnell USMember ✭✭

    I am also experiencing this and it's driving me crazy.

    06-01 12:35:25.351 D/Mono ( 2527): Searching for 'sqlite3_reset'.
    06-01 12:35:25.351 D/Mono ( 2527): Probing 'sqlite3_reset'.
    06-01 12:35:25.351 D/Mono ( 2527): Found as 'sqlite3_reset'.
    06-01 12:35:25.381 D/dalvikvm( 2527): GC_EXPLICIT freed 172K, 3% free 14258K/14599K, paused 0ms+1ms
    06-01 12:35:25.381 D/Mono ( 2527): GC_OLD_BRIDGE num-objects 66 num_hash_entries 83 sccs size 82 init 0.00ms df1 0.07ms sort 0.04ms dfs2 0.09ms setup-cb 0.04ms free-data 0.04ms links 23/23/21/4 dfs passes 172/105
    06-01 12:35:25.390 D/Mono ( 2527): GC_MINOR: (Nursery full) pause 12.09ms, total 12.38ms, bridge 7.02ms promoted 800K major 1200K los 142K
    06-01 12:35:25.390 E/mono-rt ( 2527): Stacktrace:
    06-01 12:35:25.390 E/mono-rt ( 2527):
    06-01 12:35:25.390 E/mono-rt ( 2527):
    06-01 12:35:25.390 E/mono-rt ( 2527): Attempting native Android stacktrace:
    06-01 12:35:25.390 E/mono-rt ( 2527):
    06-01 12:35:25.390 E/mono-rt ( 2527): Could not unwind with libunwind.so: Cannot load library: load_library[1091]: Library '/data/data/Reach.GCTactical.Android/lib/libunwind.so' not found
    06-01 12:35:25.390 E/mono-rt ( 2527): Could not unwind with libcorkscrew.so: Cannot load library: load_library[1091]: Library '/data/data/Reach.GCTactical.Android/lib/libcorkscrew.so' not found
    06-01 12:35:25.390 E/mono-rt ( 2527):
    06-01 12:35:25.390 E/mono-rt ( 2527): No options left to get a native stacktrace :-(
    06-01 12:35:25.390 E/mono-rt ( 2527):

  • I don't know if this is related or not, but I got the following with the latest beta (as of June 1):

    06-01 09:51:05.673: E/dalvikvm(1985): Excessive JNI global references (2001)
    06-01 09:51:05.673: E/dalvikvm(1985): VM aborting
    

    It is followed by a long stacktrace, which I've omitted.

  • BradCrandallBradCrandall USMember ✭✭

    I am also having trouble with today's Xamarin.VisualStudio_3.11.586. I guess we can add it to the list of broken GC.

  • JeremyKolbJeremyKolb USMember ✭✭✭

    I've filed https://bugzilla.xamarin.com/show_bug.cgi?id=30722 to keep track of this issue. If you guys can post a repro or more info on that bug they should be able to get to it.

  • JonathanPryorJonathanPryor USXamarin Team Xamurai

    Input. More Input!.

    Could there be a GC bug? Yes. Have I seen any evidence of one? Not yet.

    There is not enough information here to say anything at all.

    Refresher: a GREF is used for every instance of a Java.Lang.Object subclass. For example, this block of code will require 2000 GREFs:

    var strings = new List<Java.Lang.String>();
    for (int i = 0; i < 2000; ++i) {
        strings.Add (new Java.Lang.String (i.ToString ());
    }
    

    That will ~immediately crash on an emulator, as emulators have a limit of 2000 GREFs. (BOOM)

    Note, however, that the above code does not exhibit a GREF leak: all of those instances are alive, are being referenced, and cannot be collected by the GC.

    What we need is the GREF log:

    adb shell setprop debug.mono.log gref
    

    If running on Xamarin.Android 5.1 or later with a Debug build, this will generate a files/.__override__/grefs.txt log file.

    Please provide sample code which causes the crash and the corresponding GREF log, which will let us know how many GREFs have been created and where they were created from. (We need the source to ascertain if it's an actual GC bug/leak or a "bug" in the code, e.g. needing to reference "too many" instances at the same time.)

  • jelghjelgh SEMember
    edited June 2015

    Getting this in the log around the crash. It is talking about GREF @JonathanPryor
    I just updated to latest stable Xamarin, Mono and Android to get rid of the Android M crashes..

    Xamarin Studio
    Version 5.9.3 (build 1)
    Runtime:
        Mono 4.0.1 ((detached/ed1d3ec)
        GTK+ 2.24.23 (Raleigh theme)
    
        Package version: 400010044
    
    Xamarin.Android
    Version: 5.1.3.1 (Business Edition)
    Android SDK: 
        Supported Android versions:
            2.3    (API level 10)
            4.0.3  (API level 15)
            4.2    (API level 17)
            4.3    (API level 18)
            4.4    (API level 19)
            4.4.87 (API level 20)
    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)
    
    W/monodroid(11894): Trying to load sgen from: /data/app/{our.app.package}-1/lib/arm/libmonosgen-2.0.so
    W/monodroid-gc(11894): GREF GC Threshold: 46080
    W/monodroid(12494): Trying to load sgen from: /data/app/{our.app.package}-2/lib/arm/libmonosgen-2.0.so
    W/monodroid-gc(12494): GREF GC Threshold: 46080
    E/mono-rt (12494): Stacktrace:
    E/mono-rt (12494):
    E/mono-rt (12494):
    E/mono-rt (12494): Attempting native Android stacktrace:
    E/mono-rt (12494):
    E/mono-rt (12494):  at ???+0 [0x9b01a858]
    E/mono-rt (12494):  at ???+0 [0x83]
    E/mono-rt (12494):
    E/mono-rt (12494): =================================================================
    E/mono-rt (12494): Got a SIGSEGV while executing native code. This usually indicates
    E/mono-rt (12494): a fatal error in the mono runtime or one of the native libraries
    E/mono-rt (12494): used by your application.
    E/mono-rt (12494): =================================================================
    E/mono-rt (12494):
    W/monodroid(12553): Trying to load sgen from: /data/app/{our.app.package}-2/lib/arm/libmonosgen-2.0.so
    W/monodroid-gc(12553): GREF GC Threshold: 46080
    

    EDIT: Running on Nexus 6 with Android 5.1.1

  • JonathanPryorJonathanPryor USXamarin Team Xamurai

    @jelgh: Your crash does not suggest a GREF-related crash. It doesn't suggest much of anything, really; there was a crash "somewhere" in native code, with no indication of where that would be.

    Would it be possible to provide the source to your app so that we can investigate?

    Additionally, you could try enabling all the logging to see where execution reaches before it dies:

    adb shell setprop debug.mono.log all
    
  • jelghjelgh SEMember

    @JonathanPryor It all got so slow when adding all logging (lref, right...?). Couldn't get it to crash again. Unfortunately, I cannot give away our source code. Will test more tomorrow.

    Right now I have to choose between the crashes on Android M preview or these crashes. Is this correct or is it any Xamarin version that is working without crashes at the moment?

    Best,
    Johannes

  • JonathanPryorJonathanPryor USXamarin Team Xamurai

    It all got so slow when adding all logging (lref, right...?).

    Yup, lref logging is a huge perf sink.

    I was hoping it would crash quickly, and thus the lref logging wouldn't be an issue. I thought wrong.

    Instead, let's try:

    adb shell setprop debug.mono.log assembly,default,gc,gref,timing,bundle,network,netlink
    

    Right now I have to choose between the crashes on Android M preview or these crashes.

    I would suggest not focusing on Android M fixes. From what I've heard, Android M breaks lots of apps.

    The fixes in Xamarin.Android 5.1.3 should allow the default app template to work, and it allowed our unit tests to pass on Android-M, but it wouldn't surprise me if something else was going on as well.

  • BradCrandallBradCrandall USMember ✭✭

    Here is how to reproduce the problem I am seeing;

    1. Create a new project in Visual Studio using the Visual C#->Android->Blank App (Android) template.
    2. Edit MainActivity.cs and add GC.Collect(); on the button click.
    3. Deploy the app and run it, then click the button and BOOM.

      using System;
      using Android.App;
      using Android.Content;
      using Android.Runtime;
      using Android.Views;
      using Android.Widget;
      using Android.OS;

      namespace TestGC {
      [Activity(Label = "TestGC", MainLauncher = true, Icon = "@drawable/icon")]
      public class MainActivity : Activity {
      int count = 1;

          protected override void OnCreate(Bundle bundle) {
              base.OnCreate(bundle);
      
              // Set our view from the "main" layout resource
              SetContentView(Resource.Layout.Main);
      
              // Get our button from the layout resource,
              // and attach an event to it
              Button button = FindViewById<Button>(Resource.Id.MyButton);
      
              button.Click += delegate { 
                  button.Text = string.Format("called GC.Collect {0} times", count++);
                  Android.Util.Log.Info("TestGC", "Calling GC.Collect()");
                  GC.Collect();
                  Android.Util.Log.Info("TestGC", "Completed calling GC.Collect()");
              };
          }
      }
      

      }

      06-04 21:59:35.061 I/TestGC ( 2407): Calling GC.Collect()
      06-04 21:59:35.061 I/monodroid-lref( 2407): -l- lrefc 1 handle 0xb3950a00/L from thread '(null)'(1)
      06-04 21:59:35.061 I/monodroid-lref( 2407): -l- lrefc 0 handle 0xb3950a40/L from thread '(null)'(1)
      06-04 21:59:35.070 I/monodroid-gref( 2407): +w+ grefc 13 gwrefc 1 obj-handle 0x1d3001f2/G -> new-handle 0x1d200003/W from thread 'finalizer'(2407)
      06-04 21:59:35.070 I/monodroid-gref( 2407): -g- grefc 13 gwrefc 1 handle 0x1d3001f2/G from thread 'finalizer'(2407)
      06-04 21:59:35.070 I/monodroid-gref( 2407): +w+ grefc 12 gwrefc 2 obj-handle 0x1d2001ea/G -> new-handle 0x1d200007/W from thread 'finalizer'(2407)
      06-04 21:59:35.070 I/monodroid-gref( 2407): -g- grefc 12 gwrefc 2 handle 0x1d2001ea/G from thread 'finalizer'(2407)
      06-04 21:59:35.070 D/dalvikvm( 2407): GC_EXPLICIT freed 109K, 2% free 9105K/9283K, paused 0ms+1ms
      06-04 21:59:35.070 I/monodroid-gref( 2407): +g+ grefc 12 gwrefc 2 obj-handle 0x1d200003/W -> new-handle 0x1d4001f2/G from thread 'finalizer'(2407)
      06-04 21:59:35.070 I/monodroid-gref( 2407): -w- grefc 12 gwrefc 1 handle 0x1d200003/W from thread 'finalizer'(2407)
      06-04 21:59:35.070 I/monodroid-gref( 2407): +g+ grefc 13 gwrefc 1 obj-handle 0x1d200007/W -> new-handle 0x1d3001ea/G from thread 'finalizer'(2407)
      06-04 21:59:35.070 I/monodroid-gref( 2407): -w- grefc 13 gwrefc 0 handle 0x1d200007/W from thread 'finalizer'(2407)
      06-04 21:59:35.070 I/monodroid-gc( 2407): GC cleanup summary: 2 objects tested - resurrecting 2.
      06-04 21:59:35.080 D/Mono ( 2407): GC_OLD_BRIDGE num-objects 2 num_hash_entries 2 sccs size 2 init 0.00ms df1 0.00ms sort 0.04ms dfs2 0.06ms setup-cb 0.04ms free-data 0.05ms links 1/1/1/1 dfs passes 5/3
      06-04 21:59:35.080 D/Mono ( 2407): GC_MAJOR: (user request) pause 1.37ms, total 2.38ms, bridge 11.05ms major 800K/320K los 8K/56K
      06-04 21:59:35.080 E/mono-rt ( 2407): Stacktrace:
      06-04 21:59:35.080 E/mono-rt ( 2407):
      06-04 21:59:35.080 E/mono-rt ( 2407):
      06-04 21:59:35.080 E/mono-rt ( 2407): Attempting native Android stacktrace:
      06-04 21:59:35.080 E/mono-rt ( 2407):
      06-04 21:59:35.080 I/monodroid-assembly( 2407): Trying to load library '/data/data/TestGC.TestGC/lib/libunwind.so'
      06-04 21:59:35.080 I/monodroid-assembly( 2407): Trying to load library '/data/data/TestGC.TestGC/lib/libcorkscrew.so'
      06-04 21:59:35.080 E/mono-rt ( 2407): Could not unwind with libunwind.so: Cannot load library: load_library[1091]: Library '/data/data/TestGC.TestGC/lib/libunwind.so' not found
      06-04 21:59:35.080 E/mono-rt ( 2407): Could not unwind with libcorkscrew.so: Cannot load library: load_library[1091]: Library '/data/data/TestGC.TestGC/lib/libcorkscrew.so' not found
      06-04 21:59:35.080 E/mono-rt ( 2407):
      06-04 21:59:35.080 E/mono-rt ( 2407): No options left to get a native stacktrace :-(
      06-04 21:59:35.080 E/mono-rt ( 2407):
      06-04 21:59:35.080 E/mono-rt ( 2407): =================================================================
      06-04 21:59:35.080 E/mono-rt ( 2407): Got a SIGSEGV while executing native code. This usually indicates
      06-04 21:59:35.080 E/mono-rt ( 2407): a fatal error in the mono runtime or one of the native libraries
      06-04 21:59:35.080 E/mono-rt ( 2407): used by your application.
      06-04 21:59:35.080 E/mono-rt ( 2407): =================================================================
      06-04 21:59:35.080 E/mono-rt ( 2407):
      06-04 21:59:35.080 F/libc ( 2407): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=128)
      06-04 21:59:35.080 I/monodroid-lref( 2407): +l+ lrefc 1 handle 0xb394b308/L from thread '(null)'(1)
      06-04 21:59:35.080 I/monodroid-lref( 2407): +l+ lrefc 2 handle 0xb394a3b8/L from thread '(null)'(1)
      06-04 21:59:35.080 I/TestGC ( 2407): Completed calling GC.Collect()
      06-04 21:59:35.080 I/monodroid-lref( 2407): -l- lrefc 1 handle 0xb394b308/L from thread '(null)'(1)
      06-04 21:59:35.080 I/monodroid-lref( 2407): -l- lrefc 0 handle 0xb394a3b8/L from thread '(null)'(1)
      06-04 21:59:35.610 I/DEBUG ( 774): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
      06-04 21:59:35.610 I/DEBUG ( 774): Build fingerprint: 'generic_x86/sdk_x86/generic_x86:4.0.4/IMM76D/eng.juntian.20120418.185032:eng/test-keys'
      06-04 21:59:35.610 I/DEBUG ( 774): pid: 2407, tid: 2420 >>> TestGC.TestGC <<<
      06-04 21:59:35.610 I/DEBUG ( 774): signal 11 (SIGSEGV), code 128 (?), fault addr 00000000
      06-04 21:59:36.490 D/Zygote ( 777): Process 2407 terminated by signal (11)

  • jelghjelgh SEMember

    @JonathanPryor No exactly, I will downgrade Xamarin of course.
    Just annoying to get one support email, two Google Play reviews and one comment in our Google community for beta users about Android M crashes (actually one said that all other apps work but not ours).

    https://play.google.com/store/apps/details?id=se.tink.android

    /J

  • TomStandaert.0575TomStandaert.0575 BEMember ✭✭
    edited June 2015

    Seems to be also the reason of our release version crashing:

    [monodroid] Trying to load sgen from: /data/data/eu.krumb.android/lib/libmonosgen-2.0.so
    [monodroid-gc] GREF GC Threshold: 46080
    [monodroid-assembly] Could not load assembly 'KrumbAndroid' during startup registration.
    [monodroid-assembly] This might be due to an invalid debug instalation.
    [monodroid-assembly] A common cause is to 'adb install' the app directly instead of doing from the IDE.

    That problem started this morning after upgrading the android sdk, xamarin studio and xamarin.android (an action I now very much regret). When I downgrade back to 3.9.xxxx of xamarin.android the app starts correctly but has other problems (I can't for example link in release mode). As soon as I go to 3.11.xxxx the problem reappears.

    The biggest issue is that I'm certain that I was on one of the 3.11 releases before this morning (the one of the decimal hotfix) and on 5.9 of the studio. However, that combination no longer works, so it has to be the combination of thee things, the android sdk version, xamarin.android and maybe android studio.

    This places me in the very awkward position of not being able to provide my client with new builds, and this without having any explanation to give to them.
    NOT something that makes me confident of my choice to use xamarin, in fact, this isn't the first time an update broke a lot of stuff without me changing one line of code.

  • MihaMarkicMihaMarkic SI ✭✭✭✭

    @TomStandaert.5208 Does this happen on clean devices as well?

  • TomStandaert.0575TomStandaert.0575 BEMember ✭✭

    yes, but it doesn't happen on every device (only on lower end), on highend devices the build is very very unstable and slow. Also since the update.

  • CharlinCharlin DOUniversity ✭✭

    I have the same issue, only happens on Android < 4.1

  • FrankJaguschFrankJagusch DEMember

    May be this helps a bit:
    I got a similar problem (see below) on an emulated device (API Level 15, Intel Atom x86). On my real devices (both ARM, API Level 15 and 19) the problem not appears.

    [Mono] GC_BRIDGE waiting for bridge processing to finish
    [Mono] GC_OLD_BRIDGE num-objects 256 num_hash_entries 2197 sccs size 1655 init 0.00ms df1 1.02ms sort 0.00ms dfs2 0.00ms setup-cb 0.00ms free-data 1.67ms links 2718/2718/8445/14 dfs passes 5171/4373
    [Mono] GC_MINOR: (Nursery full) pause 5.70ms, total 6.46ms, bridge 34.24ms promoted 1344K major 1712K los 99K
    [mono-rt] Stacktrace:
    [mono-rt] 
    [mono-rt] 
    [mono-rt] Attempting native Android stacktrace:
    [mono-rt] 
    [mono-rt]   Could not unwind with `libunwind.so`: Cannot load library: load_library[1091]: Library '/data/data/MitanMobilLV.Android/lib/libunwind.so' not found
    [mono-rt]   Could not unwind with `libcorkscrew.so`: Cannot load library: load_library[1091]: Library '/data/data/MitanMobilLV.Android/lib/libcorkscrew.so' not found
    [mono-rt] 
    [mono-rt]   No options left to get a native stacktrace :-(
    [mono-rt] 
    [mono-rt] =================================================================
    [mono-rt] Got a SIGSEGV while executing native code. This usually indicates
    [mono-rt] a fatal error in the mono runtime or one of the native libraries 
    [mono-rt] used by your application.
    [mono-rt] =================================================================
    [mono-rt] 
    [libc] Fatal signal 11 (SIGSEGV) at 0x00000000 (code=128)
    
  • jelghjelgh SEMember

    Have anyone tried the new Xamarin release?

  • BradCrandallBradCrandall USMember ✭✭

    The last one I tried was 3.11.590 (which is the latest as of today). The latest version that works is 3.9.547.

  • CharlinCharlin DOUniversity ✭✭

    Any news about this problem?

  • JamesGreen.8031JamesGreen.8031 GBMember ✭✭

    I've done nothing useful for two weeks now. I have the Android scars to prove it. @FrankJagusch I'm seeing this error also using an API Level 15, Intel Atom x86 on Xamarin 3.11.590.0.

    I'm also starting to wonder if Xamarin is right thing to be using at all. It has so far been the worst development experience of my entire career although it seems I started at an extremely bad point in time.

    I have been advised to install beta releases twice in an extremely short space of time since the "stable" builds are essentially completely broken.

    This isn't what I paid for ...

  • JamesGreen.8031JamesGreen.8031 GBMember ✭✭

    I cannot believe that Xamarin have just release 3.11.590.0 as an upgrade on the stable pipeline when I have been talking to their engineers about how buggy it has been for me for the last few weeks.

    I'm running 3.11.666.0 here and that is working for me on ARM but not x86.

  • BradCrandallBradCrandall USMember ✭✭

    This is still a issue for the latest version which is Xamarin.VisualStudio_3.11.666.

  • JamesGreen.8031JamesGreen.8031 GBMember ✭✭
    edited July 2015

    I'm only seeing this issue if I run an x86 emulator with 3.11.666

    APILevel 15 x86 Error. The error occurs exactly at the moment I click my login button which obviously kicks off a GC process to clear down the LoginView activity.

    07-01 12:44:28.147 E/mono-rt ( 1447): Stacktrace:
    07-01 12:44:28.147 E/mono-rt ( 1447):
    07-01 12:44:28.147 E/mono-rt ( 1447):
    07-01 12:44:28.147 E/mono-rt ( 1447): Attempting native Android stacktrace:
    07-01 12:44:28.147 E/mono-rt ( 1447):
    07-01 12:44:28.147 E/mono-rt ( 1447): Could not unwind with libunwind.so: Cannot load library: load_library[1091]: Library '/data/data/Moodex.Android/lib/libunwind.so' not found
    07-01 12:44:28.147 E/mono-rt ( 1447): Could not unwind with libcorkscrew.so: Cannot load library: load_library[1091]: Library '/data/data/Moodex.Android/lib/libcorkscrew.so' not found
    07-01 12:44:28.147 E/mono-rt ( 1447):
    07-01 12:44:28.147 E/mono-rt ( 1447): No options left to get a native stacktrace :-(
    07-01 12:44:28.147 E/mono-rt ( 1447):
    07-01 12:44:28.147 E/mono-rt ( 1447): =================================================================
    07-01 12:44:28.147 E/mono-rt ( 1447): Got a SIGSEGV while executing native code. This usually indicates
    07-01 12:44:28.147 E/mono-rt ( 1447): a fatal error in the mono runtime or one of the native libraries
    07-01 12:44:28.147 E/mono-rt ( 1447): used by your application.
    07-01 12:44:28.147 E/mono-rt ( 1447): =================================================================
    07-01 12:44:28.147 E/mono-rt ( 1447):
    07-01 12:44:28.147 F/libc ( 1447): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=128)

    I have turned off the Host GPU support in the x86 emulators as there is a known issue with that at the moment.

    If I use GPU Acceleration on an ARM emulator at API level 21 I see the same issues as with an x86 emulator, it bombs instead of shutting down as expected yet this works find on API level 15.

    The screens wobbles around from portrait to landscape to completely upside down to the right way up repeatedly during startup. If I have a keyboard enabled it sticks on Landscape meaning I have to crane my neck to see it the right way up.

    These emulators appear to be utterly random in their operation. Not terribly impressed all in all.

  • JamesGreen.8031JamesGreen.8031 GBMember ✭✭

    Interestingly, If I use an Atom x86_64 emulator things seem to be fine.

Sign In or Register to comment.