Bug 43357 - WCSessionReplyHandler crashes WatchKit app
Summary: WCSessionReplyHandler crashes WatchKit app
Alias: None
Product: iOS
Classification: Xamarin
Component: Mono runtime / AOT compiler ()
Version: XI 9.99 (iOS 10 previews)
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: 10.0.0 (C8)
Assignee: Zoltan Varga
: 43178 ()
Depends on:
Blocks: 43178 43216
  Show dependency tree
Reported: 2016-08-15 17:37 UTC by ulrike_axen
Modified: 2016-09-12 09:28 UTC (History)
7 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:

Description ulrike_axen 2016-08-15 17:37:56 UTC
Sending a replyMessage to the watch app causes it to crash on real watch (not in simulator).

Use WCSession.sendMessage with a replyHandler to send a message to the phone. If the phone sends a reply (using the replyHandler), the watch app crashes.
Comment 1 Vincent Dondain [MSFT] 2016-08-16 14:26:52 UTC
Hi, we would need a bit more info in order to process this bug.

Could you please:

- Provide us your Xamarin Studio > About information so we know the exact versions of the products you are using.
- Give us a simple test case that shows the issue so we can reproduce in the same conditions as you.
- Attach some logs so we understand which kind of crash we're talking about, mostly the application output and device logs.
Comment 2 ulrike_axen 2016-08-16 14:33:44 UTC
=== Xamarin Studio Enterprise ===

Version 6.1 (build 5338)
Installation UUID: 0ca42116-8f54-4ad6-bd25-aa90f20c571f
	Mono 4.6.0 (mono-4.6.0-branch/e571108) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 406000138

=== NuGet ===


=== Xamarin.Profiler ===

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

=== Xamarin.Android ===

Version: (Xamarin Enterprise)
Android SDK: /Users/axenu/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
		5.1    (API level 22)
		6.0    (API level 23)

SDK Tools Version: 25.1.1
SDK Platform Tools Version: 23.1
SDK Build Tools Version: 23.0.3

Java SDK: /usr
java version "1.8.0_74"
Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)

Android Designer EPL code available here:

=== Xamarin Android Player ===

Not Installed

=== Apple Developer Tools ===

Xcode 8.0 (11228.2)
Build 8S193k

=== Xamarin.iOS ===

Version: (Xamarin Enterprise)
Hash: 40db5d1
Branch: cycle8
Build date: 2016-08-11 18:59:56-0400

=== Xamarin.Mac ===

Version: (Xamarin Enterprise)

=== Build Information ===

Release ID: 601005338
Git revision: 860f5d2e358077f913badaf7b14c5532888bf12c
Build date: 2016-08-11 16:20:43-04
Xamarin addins: 8bea879bcb4de08213fff5812fd54323d79889d6
Build lane: monodevelop-lion-cycle8

=== Operating System ===

Mac OS X 10.11.6
Darwin ulrikes-mbp-2.ms.starkey.com 15.6.0 Darwin Kernel Version 15.6.0
    Thu Jun 23 18:25:34 PDT 2016
    root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64
Comment 3 ulrike_axen 2016-08-16 14:35:36 UTC
For a simple test case, see bug 43178, it's the same app.

As for logs, please give me detail instructions as to how to get the logs from the watch app. The iPhone app is not crashing, it's the watch app, thanks
Comment 4 ulrike_axen 2016-08-16 15:06:00 UTC
From the xCode console, the watch reports is a segmentation fault:

Aug 16 09:54:33 Ulrikes-AppleWatch xfwatchxFUIiOSWatchApp[603] <Warning>: -[SPApplicationDelegate extensionDidTerminate:] WatchKit App killed by WatchKit daemon
Aug 16 09:54:33 Ulrikes-AppleWatch com.apple.xpc.launchd[1] (com.starkey.xfwatch.watchkitapp.watchkitextension[604]) <Notice>: Service exited due to signal: Segmentation fault: 11
Aug 16 09:54:33 Ulrikes-AppleWatch com.apple.xpc.launchd[1] (UIKitApplication:com.starkey.xfwatch.watchkitapp[0xdcb0][603]) <Warning>: Service exited with abnormal code: 1

The only thing I'm trying to do currently when the watch app gets a reply is output a message -- when debugging. I captured this log from a release build, so essentially, nothing is happening when I receive the reply (except a crash). The phone app does receive the message and act on it. I have to comment out the line of code in the phone app that sends the reply in order for the watch app to NOT crash

code snippet:

(replyMessage) => {
// todo: unpack reply... for connection status
									Debug.WriteLine("Did receive reply to send Volume command");
Comment 5 ulrike_axen 2016-08-17 20:55:37 UTC
Hello, please let me know if you need more info... I think I have supplied everything that was requested
Comment 8 Vincent Dondain [MSFT] 2016-08-21 19:02:39 UTC

All information provided. I can reliably reproduce the issue locally with the app from bug #43178.

I'm making the bug as confirmed, further investigation needed.
Comment 9 Vincent Dondain [MSFT] 2016-08-21 19:22:05 UTC
However it's important to notice that this issue is only happening on RELEASE mode as it is working fine with DEBUG mode.
Comment 10 ulrike_axen 2016-08-22 13:40:52 UTC
But in debug mode I cannot deploy to the (real) watch. From my report, this works fine on the simulator, but does not work on the real device. I am not sure if debug/release has anything to do with it. I can try release mode on the simulator.
Comment 11 Vincent Dondain [MSFT] 2016-08-22 17:13:47 UTC
@ulrike, I can deploy your app on an Apple Watch device in debug mode and it works just fine ;)

There's a pretty big difference in the project options used between Debug and Release. The release mode is using LLVM and bitcode (and that's where stuff can sadly break).

Now we have all the information we need and will be able to act on the issue.

Note: I'm using those versions of the product to deploy on real device:

Feel free to try the beta or alpha channel and our daily builds of XI (https://github.com/xamarin/xamarin-macios/wiki) to see if you can also deploy on device.

=== Xamarin Studio Enterprise ===

Version 6.2 (build 355)
Installation UUID: 276439ce-67ad-434d-89e9-b46e0bdbc7ce
	Mono 4.6.0 (mono-4.6.0-branch/700a14a) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 406000133

=== Apple Developer Tools ===

Xcode 8.0 (11239.2)
Build 8S201h

=== Xamarin.Mac ===

Version: (Xamarin Enterprise)

=== Xamarin.iOS ===

Version: (Xamarin Enterprise)
Hash: 2a0702e
Branch: xcode8
Build date: 2016-08-18 19:28:59+0200

=== Build Information ===

Release ID: 602000355
Git revision: 795bbb66b7d41dbbe908342a04a9e1348fab5c19
Build date: 2016-08-16 13:37:53-04
Xamarin addins: 159d5850a21119ebef9ce39c10d0760ec3cd963b
Build lane: monodevelop-mdaddins-master

=== Operating System ===

Mac OS X 10.11.6
Darwin MacBook-Pro-2.local 15.6.0 Darwin Kernel Version 15.6.0
    Thu Jun 23 18:25:34 PDT 2016
    root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64
Comment 12 Rolf Bjarne Kvinge [MSFT] 2016-08-23 17:30:30 UTC
I can reproduce the crash, here's a stack trace from lldb:

> (lldb) bt
> * thread #13: tid = 0xb962, 0x24e45bb6 libsystem_pthread.dylib`<redacted> + 10, name = 'tid_300f', queue = 'NSOperationQueue 0x145e0b50 :: NSOperation 0x145eb030 (QOS: UTILITY)', stop reason = EXC_BAD_ACCESS (code=1, address=0xb0)
>   * frame #0: 0x24e45bb6 libsystem_pthread.dylib`<redacted> + 10
>     frame #1: 0x00082c06 xfwatchxFUIiOSWatchAppExtension`mini_lookup_method [inlined] mono_os_mutex_lock(mutex=0x000000b0) + 6 at mono-os-mutex.h:96 [opt]
>     frame #2: 0x00082c00 xfwatchxFUIiOSWatchAppExtension`mini_lookup_method(domain=0x00000000, method=0x14c2b048, shared=0x00000000) + 20 at mini-runtime.c:1710 [opt]
>     frame #3: 0x000832c8 xfwatchxFUIiOSWatchAppExtension`mono_jit_find_compiled_method_with_jit_info [inlined] lookup_method(domain=0x00000000, method=0x14c2b048) + 10 at mini-runtime.c:1738 [opt]
>     frame #4: 0x000832be xfwatchxFUIiOSWatchAppExtension`mono_jit_find_compiled_method_with_jit_info(domain=0x00000000, method=0x14c2b048, ji=0x00000000) + 42 at mini-runtime.c:2063 [opt]
>     frame #5: 0x000897cc xfwatchxFUIiOSWatchAppExtension`mono_create_jit_trampoline(domain=0x00000000, method=<unavailable>, error=0x1f3c3bd4) + 86 at mini-trampolines.c:1520 [opt]
>     frame #6: 0x00082592 xfwatchxFUIiOSWatchAppExtension`mono_resolve_patch_target(method=<unavailable>, domain=0x00000000, code=<unavailable>, patch_info=<unavailable>, run_cctors=<unavailable>, error=0x1f3c3bd4) + 274 at mini-runtime.c:1379 [opt]
>     frame #7: 0x00056be2 xfwatchxFUIiOSWatchAppExtension`init_method(amodule=<unavailable>, method_index=<unavailable>, method=<unavailable>, init_class=<unavailable>, context=<unavailable>, error=0x1f3c3bd4) + 860 at aot-runtime.c:4213 [opt]
>     frame #8: 0x00050d32 xfwatchxFUIiOSWatchAppExtension`mono_aot_init_llvm_method [inlined] init_llvmonly_method(method=<unavailable>) + 14 at aot-runtime.c:4260 [opt]
>     frame #9: 0x00050d24 xfwatchxFUIiOSWatchAppExtension`mono_aot_init_llvm_method(aot_module=<unavailable>, method_index=3102695) + 8 at aot-runtime.c:4274 [opt]
>     frame #10: 0x002b3d2c xfwatchxFUIiOSWatchAppExtension`init_method + 24
>     frame #11: 0x002f580c xfwatchxFUIiOSWatchAppExtension`Xamarin_WatchOS_wrapper_native_to_managed_ObjCRuntime_Trampolines_SDWCSessionReplyHandler_Invoke_intptr_intptr + 38
>     frame #12: 0x30033030 WatchConnectivity`__67-[WCSession onqueue_handleResponseDictionary:record:withPairingID:]_block_invoke + 348
>     frame #13: 0x2593885a Foundation`__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 10
>     frame #14: 0x2589e5f6 Foundation`-[NSBlockOperation main] + 70
>     frame #15: 0x25891552 Foundation`-[__NSOperationInternal _start:] + 606
>     frame #16: 0x2593a778 Foundation`__NSOQSchedule_f + 192
>     frame #17: 0x24c60436 libdispatch.dylib`_dispatch_client_callout + 6
>     frame #18: 0x24c6151a libdispatch.dylib`_dispatch_queue_drain$VARIANT$up + 1734
>     frame #19: 0x24c61d40 libdispatch.dylib`_dispatch_queue_invoke$VARIANT$up + 288
>     frame #20: 0x24c893ec libdispatch.dylib`_dispatch_root_queue_drain + 372
>     frame #21: 0x24c89272 libdispatch.dylib`_dispatch_worker_thread3 + 94
>     frame #22: 0x24e41a36 libsystem_pthread.dylib`_pthread_wqthread + 906
>     frame #23: 0x24e41698 libsystem_pthread.dylib`start_wqthread + 12> 

This looks like a runtime problem, since the crash appears to occur because there's no current appdomain (several frames have domain=0x00000000 as a parameter).

Frame 12 is the watch calling a managed delegate (frame 11), which means no code from Xamarin.iOS is involved (so my guess is that the native_to_managed wrapper doesn't set the current domain properly).
Comment 13 Zoltan Varga 2016-08-24 20:20:21 UTC
It happens because some initialization code is ran before the thread is attached to the runtime. Will fix.
Comment 14 Zoltan Varga 2016-08-25 20:28:33 UTC
Fixed in mono master dcd650d6fc59817b1efd6fc088ac41ce304a41c2/4.6 14f694dd392532b0e340fa12edf0965420b332cb.
Comment 16 Rolf Bjarne Kvinge [MSFT] 2016-08-26 11:24:13 UTC
*** Bug 43178 has been marked as a duplicate of this bug. ***
Comment 17 Danish Akhtar 2016-08-30 11:37:33 UTC
I have tried to reproduce this issue with X.iOS and Xcode 8beta 6 mentioned in Comment 2, steps  I have followed to reproduce this issue are:

1. Download attached test case from Bug 43178.
2. Open test project in XS.
3. Uncomment line 46 of the file TruLinkDataParser.cs in the WatchAppExtension project.
4. Run the application in Release mode on Watch device 2.2 and Watch 3.0.

Observed that application doesn't crashed on Watch devices when running in Release mode. So I am unable to reproduce this issue.

Supplement info:
Application output: https://gist.github.com/Prashant360/c45b9a01dad0ae9c1ab32a1a8207a6f7
ide logs and Env info: https://gist.github.com/anonymous/cabfc66a55929cf489771b9f26c8472a
Watch logs via Xcode: https://gist.github.com/Prashant360/c9b1b59ad3626172f00c1c94e9ca9ca6

@Rolf: Could you please have a look, What I missed here to Reproduce this issue?

Comment 18 ulrike_axen 2016-08-30 13:21:09 UTC
I believe this has been marked as a duplicate of 43178, and is considered resolved.
Comment 19 Rolf Bjarne Kvinge [MSFT] 2016-08-30 13:23:14 UTC
@Danish, you have to open the corresponding app on the phone as well, make sure the watch and phone apps are connected, and maybe play a bit with the values, for the crash to occur.
Comment 20 Danish Akhtar 2016-09-12 09:28:08 UTC
@Rolf: After following steps mentioned in Comment 19, still I am not able to reproduce this issue. Application is deployed successfully on watch device in Release mode without any crash. So, As of now I am closing this issue.

@ulrike_axen@starkey.com: Please feel free to Reopen it, if you are getting this issue again with latest builds.