Bug 43592 - scheduleBackgroundRefreshTask throws [NSMethodSignature signatureWithObjCTypes:]: type signature is empty
Summary: scheduleBackgroundRefreshTask throws [NSMethodSignature signatureWithObjCType...
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.WatchOS.dll ()
Version: XI 9.99 (iOS 10 previews)
Hardware: PC Mac OS
: --- normal
Target Milestone: Xcode8 (iOS10)
Assignee: Rolf Bjarne Kvinge [MSFT]
Depends on:
Reported: 2016-08-22 12:54 UTC by Christer Nordvik
Modified: 2016-08-29 14:18 UTC (History)
4 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 Christer Nordvik 2016-08-22 12:54:13 UTC
I am implementing background tasks in Apple Watch and once I schedule the task, the app crashes. 

The implementation can be empty and it never reaches it. 

I am using the exact same code as here: 

public override void HandleBackgroundTasks(NSSet<WKRefreshBackgroundTask> backgroundTasks)

2016-08-22 14:36:01.378 FotMobFotMobWatchAppV2Extension[80523:5538571] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSMethodSignature signatureWithObjCTypes:]: type signature is empty.'
*** First throw call stack:
	0   CoreFoundation                      0x01356a22 __exceptionPreprocess + 194
	1   libobjc.A.dylib                     0x0563ee76 objc_exception_throw + 52
	2   CoreFoundation                      0x012d239a +[NSMethodSignature signatureWithObjCTypes:] + 1114
	3   Foundation                          0x00991fb5 -[NSXPCConnection _sendInvocation:withProxy:remoteInterface:withErrorHandler:timeout:userInfo:] + 1771
	4   Foundation                          0x009a086f -[NSXPCConnection _sendInvocation:withProxy:remoteInterface:] + 44
	5   Foundation                          0x009a083b -[_NSXPCDistantObject forwardInvocation:] + 78
	6   CoreFoundation                      0x012d57a8 ___forwarding___ + 472
	7   CoreFoundation                      0x012d55ae _CF_forwarding_prep_0 + 14
	8   WatchKit                            0x04cca03e __94-[SPRemoteInterface scheduleBackgroundRefreshTask:preferredDate:userInfo:scheduledCompletion:]_block_invoke_2 + 321
	9   WatchKit                            0x04cc952a __61-[SPRemoteInterface runTaskOnApplicationCompanionConnection:]_block_invoke + 104
	10  WatchKit                            0x04ce4f49 +[SPUtils dispatchAsyncToMainThread:] + 61
	11  WatchKit                            0x04cc949c -[SPRemoteInterface runTaskOnApplicationCompanionConnection:] + 127
	12  WatchKit                            0x04cc9ec9 __94-[SPRemoteInterface scheduleBackgroundRefreshTask:preferredDate:userInfo:scheduledCompletion:]_block_invoke + 143
	13  libdispatch.dylib                   0x06031c4f _dispatch_call_block_and_release + 15
	14  libdispatch.dylib                   0x0605450f _dispatch_client_callout + 14
	15  libdispatch.dylib                   0x0603ae31 _dispatch_main_queue_callback_4CF + 1031
	16  CoreFoundation                      0x01316e7e __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 14
	17  CoreFoundation                      0x012d9dcf __CFRunLoopRun + 2319
	18  CoreFoundation                      0x012d924b CFRunLoopRunSpecific + 395
	19  CoreFoundation                      0x012d90ab CFRunLoopRunInMode + 123
	20  Foundation                          0x00989192 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 308
	21  Foundation                          0x0098904f -[NSRunLoop(NSRunLoop) run] + 69
	22  libxpc.dylib                        0x0634c8a5 _xpc_objc_main + 476
	23  libxpc.dylib                        0x0634f175 xpc_main + 215
	24  Foundation                          0x009e7880 +[NSXPCListener serviceListener] + 0
	25  PlugInKit                           0x11a4d6b6 -[PKService run] + 954
	26  WatchKit                            0x04cf7440 main + 148
	27  FotMobFotMobWatchAppV2Extension     0x002c8297 xamarin_main + 3415
	28  FotMobFotMobWatchAppV2Extension     0x002dacfc xamarin_watchextension_main + 124
	29  libdyld.dylib                       0x0608d85d start + 1
libc++abi.dylib: terminating with uncaught exception of type NSException

Xamarin Studio Business
Version 6.1 (build 5345)
Installation UUID: 65a8b3b7-cbad-4483-81bd-4b373e379f95
	Mono 4.6.0 (mono-4.6.0-branch/d0fc1a6) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 406000150


Not Installed

Apple Developer Tools
Xcode 8.0 (11239.2)
Build 8S201h

Version: (Xamarin Business)
Hash: 9eca876
Branch: cycle8
Build date: 2016-08-16 18:22:42-0400

Build Information
Release ID: 601005345
Git revision: fc3ab7c0cc891ef8c9867558d026257fc4654758
Build date: 2016-08-16 18:26:59-04
Xamarin addins: 695f42de8ea790cc717ccd388f2becfa35e704ae
Build lane: monodevelop-lion-cycle8
Comment 1 Rolf Bjarne Kvinge [MSFT] 2016-08-25 10:07:02 UTC
PR: https://github.com/xamarin/xamarin-macios/pull/662
Comment 2 Rolf Bjarne Kvinge [MSFT] 2016-08-25 10:10:52 UTC
QA: test case available here: https://github.com/rolfbjarne/TestApp/tree/bug43592. With the fix a line "Scheduled:" should be printed to the Application Output (from ExtensionDelegate.cs:39), without the fix that line is not printed.
Comment 3 Sebastien Pouliot 2016-08-25 15:45:49 UTC
merged in xamarin-macios/xcode8 d99d8c8cbe37ebaa7083ef73288a772f3d2cf5d0
Comment 4 Rolf Bjarne Kvinge [MSFT] 2016-08-26 15:15:42 UTC
This is still happening, it looks like the same code found two bugs (the one I originally fixed is not the same issue as reported though).

The actual issue is that Apple's code stores the pointer to the signature in the descriptor in the block for the callback (passed to WKExtension.SharedExtension.ScheduleBackgroundRefresh) somewhere (i.e. expects the signature string to never be freed), and then tries to use that pointer later (when it points to freed memory in our case).

I have not been able to create a similar scenario in Xcode (because clang will always create a statically allocated structure for the descriptor and the corresponding signature string, so it's effectively never be freed).

Unfortunately there's no real documentation about this, so it's not clear that this is an Apple bug (i.e. we'll have to cope somehow).
Comment 5 Rolf Bjarne Kvinge [MSFT] 2016-08-26 16:12:39 UTC
New PR: https://github.com/xamarin/xamarin-macios/pull/683
Comment 6 Rolf Bjarne Kvinge [MSFT] 2016-08-26 17:31:51 UTC
PR merged (xcode8 branch): https://github.com/xamarin/xamarin-macios/commit/36ea73ca6588e70d7ba8f1f5db3af5ad532a1aa3