*** Bug 36017 has been marked as a duplicate of this bug. ***
I am able to reproduce it here.
It behaves randomly. Sometime it just works OK and debugger breaks on
System.MissingMethodException: Default constructor not found for type Xamarin.Forms.Controls.CoreMasterDetailPage
when selecting "SwapRoot - MasterDetailPage" - probably too many things linked out.
Sometimes it just crashes on start, without any stack trace in the logcat - which is weird.
Might be related to
11-30 20:56:05.179 14533 15922 W OpenGLRenderer: Incorrectly called buildLayer on View: ShortcutAndWidgetContainer, destroying layer...
Note for me, the project uses debugging without shared runtime and fast deployment. Might be related too.
OK, got better info with master
#0 0xf72dabe0 in tgkill () from /Users/rodo/git/Duplo/Xamarin.Forms.ControlGallery.Android/gdb-symbols/libc.so
#1 0xf72d8f14 in pthread_kill () from /Users/rodo/git/Duplo/Xamarin.Forms.ControlGallery.Android/gdb-symbols/libc.so
#2 0xf72b5742 in raise () from /Users/rodo/git/Duplo/Xamarin.Forms.ControlGallery.Android/gdb-symbols/libc.so
#3 0xf72b28f4 in __libc_android_abort () from /Users/rodo/git/Duplo/Xamarin.Forms.ControlGallery.Android/gdb-symbols/libc.so
#4 0xf72b04b4 in abort () from /Users/rodo/git/Duplo/Xamarin.Forms.ControlGallery.Android/gdb-symbols/libc.so
#5 0xf3fb6de8 in monoeg_log_default_handler (log_domain=<optimized out>, log_level=G_LOG_LEVEL_ERROR, message=<optimized out>, unused_data=<optimized out>) at /Users/builder/data/lanes/1196/807dde35/source/mono/eglib/src/goutput.c:162
#6 0xf3fb6f8c in monoeg_g_logv (log_domain=log_domain@entry=0x0, log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x0, args=..., args@entry=...) at /Users/builder/data/lanes/1196/807dde35/source/mono/eglib/src/goutput.c:113
#7 0xf3fb700c in monoeg_assertion_message (format=0xf3fc3138 "* Assertion at %s:%d, condition `%s' not met\n") at /Users/builder/data/lanes/1196/807dde35/source/mono/eglib/src/goutput.c:133
#8 0xf3ee90ac in mono_marshal_get_synchronized_wrapper (method=method@entry=0xd0f87108) at /Users/builder/data/lanes/1196/807dde35/source/mono/mono/metadata/marshal.c:8880
#9 0xf3e628a4 in common_call_trampoline_inner (regs=regs@entry=0xff7f2280, code=code@entry=0xd0f53a6c "\016", m=m@entry=0xd0f87108, vt=vt@entry=0xd0fee460, vtable_slot=<optimized out>, vtable_slot@entry=0xd0fee518)
#10 0xf3e6314c in common_call_trampoline (vtable_slot=0xd0fee518, vt=0xd0fee460, m=0xd0f87108, code=0xd0f53a6c "\016", regs=0xff7f2280) at /Users/builder/data/lanes/1196/807dde35/source/mono/mono/mini/mini-trampolines.c:683
#11 mono_vcall_trampoline (regs=0xff7f2280, code=0xd0f53a6c "\016", slot=<optimized out>, tramp=<optimized out>) at /Users/builder/data/lanes/1196/807dde35/source/mono/mono/mini/mini-trampolines.c:767
#12 0xef6fa8f0 in ?? ()
#13 0xef6fa8f0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Alex, could you please take a look at it?
I have found the logcat output for the above assert. Not sure how relevant it is as I am not able to repro the crash in the gdb anymore with the fresh build.
12-04 10:29:14.363 13016 13016 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 13016 (dControlGallery)
12-04 10:29:14.439 3763 3763 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
12-04 10:29:14.440 3763 3763 F DEBUG : Build fingerprint: 'google/angler/angler:6.0/MDB08L/2343525:user/release-keys'
12-04 10:29:14.441 3763 3763 F DEBUG : Revision: '0'
12-04 10:29:14.441 3763 3763 F DEBUG : ABI: 'arm'
12-04 10:29:14.442 3763 3763 F DEBUG : pid: 13016, tid: 13016, name: dControlGallery >>> AndroidControlGallery.AndroidControlGallery <<<
12-04 10:29:14.442 3763 3763 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
12-04 10:29:14.488 3763 3763 F DEBUG : Abort message: '* Assertion at /Users/builder/data/lanes/1196/807dde35/source/mono/mono/metadata/marshal.c:8880, condition `enter_method' not met
12-04 10:29:14.488 3763 3763 F DEBUG : '
12-04 10:29:14.488 3763 3763 F DEBUG : r0 00000000 r1 000032d8 r2 00000006 r3 f7566b7c
12-04 10:29:14.488 3763 3763 F DEBUG : r4 f7566b84 r5 f7566b34 r6 0000001e r7 0000010c
12-04 10:29:14.488 3763 3763 F DEBUG : r8 d122bfe8 r9 00000000 sl 00000000 fp f401a660
12-04 10:29:14.489 3763 3763 F DEBUG : ip 00000006 sp ff7f1f10 lr f72d8f15 pc f72dabe0 cpsr 400e0010
12-04 10:29:14.495 3763 3763 F DEBUG :
12-04 10:29:14.495 3763 3763 F DEBUG : backtrace:
12-04 10:29:14.495 3763 3763 F DEBUG : #00 pc 00041be0 /system/lib/libc.so (tgkill+12)
12-04 10:29:14.496 3763 3763 F DEBUG : #01 pc 0003ff11 /system/lib/libc.so (pthread_kill+32)
12-04 10:29:14.496 3763 3763 F DEBUG : #02 pc 0001c73f /system/lib/libc.so (raise+10)
12-04 10:29:14.496 3763 3763 F DEBUG : #03 pc 000198f1 /system/lib/libc.so (__libc_android_abort+34)
12-04 10:29:14.496 3763 3763 F DEBUG : #04 pc 000174b0 /system/lib/libc.so (abort+4)
12-04 10:29:14.496 3763 3763 F DEBUG : #05 pc 0020fde4 /data/app/Mono.Android.DebugRuntime-1/lib/arm64/libmonosgen-32bit-2.0.so
12-04 10:29:14.914 3763 3763 F DEBUG :
12-04 10:29:14.914 3763 3763 F DEBUG : Tombstone written to: /data/tombstones/tombstone_01
I have also tried to attach gdb when running the app from Xamarin Studio.
I had to suppress SIGSYS and SIGTTOU and then I was able to start the app in 64bit ABI.
In 32bit case I am unable to start the app (running from XS and attaching gdb from terminal). It either locks up or crashes, without usable backtrace though:
0xf72db4ec in nanosleep () from /Users/rodo/git/Duplo/Xamarin.Forms.ControlGallery.Android/gdb-symbols/libc.so
[New Thread 20189]
[New Thread 20193]
[New Thread 20194]
Program received signal SIGSEGV, Segmentation fault.
0xd8252fcc in ?? ()
#0 0xd8252fcc in ?? ()
#1 0xf4ac0000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I don't have time to take a full look at this immediately, but a cursory glance makes me think it's a linker issue.
The runtime is looking for `System.Threading.Monitor.enter_with_atomic_var (object, ref bool)` and doesn't find it. There was a change a while back to use this overload in `MethodImplOptions.Synchronized` methods: https://github.com/mono/mono/commit/f68990d7c1cd729fe3cc3ccd7ce804a813e2c0b7
Looking at XA's mscorlib.xml linker descriptor, this method isn't preserved in the same way that `Enter` and `Exit` are.
Can you try and see if a linker descriptor entry fixes this? Otherwise I'll get to it sometime this week.
(BTW, that 'useless' GDB backtrace is likely because those frames are JIT'd methods - use `p mono_pmip ($pc)` at a frame to resolve it to a managed method name.)
*** Bug 36859 has been marked as a duplicate of this bug. ***
I am able to reproduce the crash from comment #8 with uptodate master.
mono_pmip ($pc) shows it crashes in
(gdb) p mono_pmip ($pc)
$1 = 0xe82ad0e0 " System.Threading.Timer:.ctor (System.Threading.TimerCallback,object,int,int) + 0x44 (0xe820fc08 0xe820fd40) [0xee9f66c0 - RootDomain]"
see https://gist.github.com/radekdoulik/143477e40a9e947dbcc3 for more info
The constructor is really simple:
public Timer (TimerCallback callback)
this.Init (callback, this, -1, -1);
so it looks like runtime issue to me.
Here is the disassembled code around the place of SIGSEGV crash.
Not sure how to proceed from here.
Joao, could you take a look?
Note that it is a random bug and for me happens in cca 1 of 10 runs or so.
The linker also doesn't influence it, it happens when linker behavior is set to Don't link as well.
Probable "dupe": Bug #35739.
@Grendel: Once you get a new 64-bit nexus device (6P or 5X), could you please investigate this ART crash?
> art/runtime/fault_handler.cc:117] Check failed: !initialized_
I still don't have the device :(
Should be fixed as of monodroid/cycle7/f11aaf3be7033b733b9ff8d1635a62a024628f9e.
This bug is a combination of a bug condition in ART (fixed in the newer versions of it, although not completely, details below) and of the way Mono debugging on Android works.
Mono uses SIGSEGV to implement single-stepping (before anyone asks - this is a good way to jump out of managed code into the native one - the segfault handler takes over and proceeds accordingly) which, unfortunately, clashes with the segfault handler inside ART. The ART handler attempts to be smart and avoid nested segfaults in *Java* generated code. It does that by unhooking ART signal handler when running generated code and restoring the original handler for the duration of the generated code run, then plugging its own handler back in. This bug is triggered by an assumption in ART that the segfault handler will *always* be swapped out while Java generated code runs, which is obviously not the case with Xamarin.Android. The buggy version thus calls the ART handler initialization *twice* and thus the assertion which is the subject of this bug. Newer versions of ART (I checked master) fix the issue almost completely - they just leave a very tiny race condition which *may* be hit by Mono sometimes. Unfortunately, I don't see a way to fix that race condition in ART so we'll have to live with it (but do read on).
The workaround (and a long-term fix for the issue) is to use software breakpoints implemented by the Mono runtime. Those breakpoints don't use the SIGSEGV mechanism but instead inject CPU-specific code to single-step. Transitioning to software breakpoints is a long-term goal for the Mono runtime on the supported platforms. Unfortunately, there is a bug in the currently released versions of Mono which makes the software breakpoints fail on Linux and ARM machines - thus on Android.
All of the issues we found with the software breakpoints are fixed in the upcoming Cycle 7 Xamarin.Android alpha. This release will default to software breakpoints so you should no longer see the assertion and you should be able to debug your applications without issues.
If you do see the assertion, however, it probably means that some other native code mapped into the Xamarin.Android app segfaults and triggers the assertion.
*** This bug has been marked as a duplicate of bug 35739 ***