Bug 35798 - Unable to maintain a debug session on new Nexus devices with certain projects
Summary: Unable to maintain a debug session on new Nexus devices with certain projects
Status: RESOLVED DUPLICATE of bug 35739
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 6.0.0
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: 6.1 (C7)
Assignee: Marek Habersack
: 36017 36859 ()
Depends on:
Reported: 2015-11-11 18:45 UTC by Peter Collins
Modified: 2016-04-15 15:11 UTC (History)
9 users (show)

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

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:

Comment 1 Peter Collins 2015-11-18 23:47:17 UTC
*** Bug 36017 has been marked as a duplicate of this bug. ***
Comment 3 Radek Doulik 2015-11-30 20:07:48 UTC
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...
Comment 4 Radek Doulik 2015-11-30 21:43:29 UTC
Note for me, the project uses debugging without shared runtime and fast deployment. Might be related too.
Comment 5 Radek Doulik 2015-12-04 11:21:27 UTC
OK, got better info with master

(gdb) bt
#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)
    at /Users/builder/data/lanes/1196/807dde35/source/mono/mono/mini/mini-trampolines.c:561
#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?)
Comment 6 Radek Doulik 2015-12-04 11:22:50 UTC
Alex, could you please take a look at it?
Comment 7 Radek Doulik 2015-12-04 17:51:38 UTC
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
Comment 8 Radek Doulik 2015-12-04 17:54:35 UTC
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
(gdb) c
[New Thread 20189]
[New Thread 20193]
[New Thread 20194]

Program received signal SIGSEGV, Segmentation fault.
0xd8252fcc in ?? ()
(gdb) bt
#0  0xd8252fcc in ?? ()
#1  0xf4ac0000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Comment 9 Alex Rønne Petersen 2015-12-07 09:00:20 UTC
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.)
Comment 12 Peter Collins 2015-12-11 21:26:49 UTC
*** Bug 36859 has been marked as a duplicate of this bug. ***
Comment 14 Radek Doulik 2015-12-16 22:54:26 UTC
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
Comment 15 Radek Doulik 2015-12-18 14:06:17 UTC
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.
Comment 17 Jonathan Pryor 2016-02-02 19:59:27 UTC
Probable "dupe": Bug #35739.
Comment 18 Jonathan Pryor 2016-02-02 20:03:07 UTC
@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_
Comment 19 Marek Habersack 2016-02-18 13:09:17 UTC
I still don't have the device :(
Comment 20 Peter Collins 2016-04-08 02:44:08 UTC
Should be fixed as of monodroid/cycle7/f11aaf3be7033b733b9ff8d1635a62a024628f9e.
Comment 21 Marek Habersack 2016-04-11 14:52:17 UTC
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.
Comment 22 Peter Collins 2016-04-15 15:11:53 UTC

*** This bug has been marked as a duplicate of bug 35739 ***