Error messages aren't meant to be an exercise in mental capacity, so make
things easier for developers to figure out which versions are valid and which
are not by sorting them.
So instead of this:
Valid Mac Catalyst versions are: 15.0, 13.3.1, 16.2, 14.3, 15.5, 13.1, 16.0, 17.2, 14.1, 15.3, 16.5, 14.6, 13.4, 17.0, 16.3, 15.6, 13.2, 14.4, 16.1, 14.2, 15.4, 16.6, 13.5, 14.7, 17.1, 15.2, 14.0, 16.4, 13.3, 14.5
We now get:
Valid Mac Catalyst versions are: 13.1, 13.2, 13.3, 13.3.1, 13.4, 13.5, 14.0, 14.1, 14.2, 14.3, 14.4, 14.5, 14.6, 14.7, 15.0, 15.2, 15.3, 15.4, 15.5, 15.6, 16.0, 16.1, 16.2, 16.3, 16.4, 16.5, 16.6, 17.0, 17.1, 17.2
From https://developer.apple.com/news/?id=3d8a9yyh
> Starting March 13: If you upload a new or updated app to App Store
Connect that uses an API requiring approved reasons, we'll will send you
an email letting you know if you’re missing reasons in your app’s
privacy manifest. This is in addition to the existing notification in
App Store Connect.
>
> Starting May 1: You’ll need to include approved reasons for the listed
APIs used by your app’s code to upload a new or updated app to App Store
Connect. If you’re not using an API for an allowed reason, please find
an alternative. And if you add a new third-party SDK that’s on the list
of commonly used third-party SDKs, these API, privacy manifest, and
signature requirements will apply to that SDK. Make sure to use a
version of the SDK that includes its privacy manifest and note that
signatures are also required when the SDK is added as a binary
dependency.
[Document
preview](928100b38f/docs/apple-privacy-manifest.md)
fixes: https://github.com/xamarin/xamarin-macios/issues/20059
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
Our tool to inject documentation for Apple APIs live in maccore, so if that
part of the build isn't enabled, we'll get a lot of false positives.
Instead just ignore the test if the Xamarin bits (in maccore) aren't enabled.
Calling [Try]SetResult on a default TaskCompletionSource will call any
continuations on the same thread.
This can lead to deadlocks (thus the hack to run TrySetResult in a background
thread), so avoid it by configuring the TaskCompletionSource to call
continutations asynchronously.
Ref: https://devblogs.microsoft.com/premier-developer/the-danger-of-taskcompletionsourcet-class/
There's a random ObjectDisposedException occurring, which seems to have this sequence of events:
1. The request is sent.
2. The request is cancelled.
3. The InflightData instance is removed here: c3437328bf/src/Foundation/NSUrlSessionHandler.cs (L545)
3a. The InflightData is disposed: c3437328bf/src/Foundation/NSUrlSessionHandler.cs (L224)
3a. The InflightData.CancellationTokenSource instance is disposed: c3437328bf/src/Foundation/NSUrlSessionHandler.cs (L1168)
4. Data comes in (in the DidReceiveData callback), and SetResponse is called: c3437328bf/src/Foundation/NSUrlSessionHandler.cs (L932)
4a. The SetResponse method tries to use InflightData.CancellationTokenSource, and that throws an ObjectDisposedException: c3437328bf/src/Foundation/NSUrlSessionHandler.cs (L970)
Full stack traces:
```
InflightData disposed:
at System.Net.Http.NSUrlSessionHandler.InflightData.Dispose(Boolean disposing) in xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:line 1168
at System.Net.Http.NSUrlSessionHandler.InflightData.Dispose() in xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:line 1160
at System.Net.Http.NSUrlSessionHandler.RemoveInflightData(NSUrlSessionTask task, Boolean cancel) in xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:line 224
at System.Net.Http.NSUrlSessionHandler.<>c__DisplayClass58_0.<SendAsync>b__0() in xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:line 545
at System.Threading.CancellationToken.<>c.<Register>b__12_0(Object obj)
at System.Threading.CancellationTokenSource.Invoke(Delegate d, Object state, CancellationTokenSource source)
at System.Threading.CancellationTokenSource.CallbackNode.<>c.<ExecuteCallback>b__9_0(Object s)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.CancellationTokenSource.CallbackNode.ExecuteCallback()
at System.Threading.CancellationTokenSource.ExecuteCallbackHandlers(Boolean throwOnFirstException)
at System.Threading.CancellationTokenSource.NotifyCancellation(Boolean throwOnFirstException)
at System.Threading.CancellationTokenSource.LinkedNCancellationTokenSource.<>c.<.cctor>b__4_0(Object s)
at System.Threading.CancellationTokenSource.Invoke(Delegate d, Object state, CancellationTokenSource source)
at System.Threading.CancellationTokenSource.CallbackNode.ExecuteCallback()
at System.Threading.CancellationTokenSource.ExecuteCallbackHandlers(Boolean throwOnFirstException)
at System.Threading.CancellationTokenSource.NotifyCancellation(Boolean throwOnFirstException)
at System.Threading.CancellationTokenSource.TimerCallback(Object state)
at System.Threading.TimerQueueTimer.CallCallback(Boolean isThreadPool)
at System.Threading.TimerQueueTimer.Fire(Boolean isThreadPool)
at System.Threading.TimerQueue.FireNextTimers()
at System.Threading.TimerQueue.System.Threading.IThreadPoolWorkItem.Execute()
at System.Threading.ThreadPoolWorkQueue.DispatchItemWithAutoreleasePool(Object workItem, Thread currentThread)
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
at System.Threading.Thread.StartCallback()
```
```
ObjectDisposedException:
*** Terminating app due to uncaught exception 'System.ObjectDisposedException', reason: 'The CancellationTokenSource has been disposed. (System.ObjectDisposedException)
at System.Net.Http.NSUrlSessionHandler.NSUrlSessionHandlerDelegate.SetResponse(InflightData inflight) in xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:line 970
at System.Net.Http.NSUrlSessionHandler.NSUrlSessionHandlerDelegate.DidReceiveData(NSUrlSession session, NSUrlSessionDataTask dataTask, NSData data) in xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:line 932
'
*** First throw call stack:
(
0 CoreFoundation 0x0000000186e72ccc __exceptionPreprocess + 176
1 libobjc.A.dylib 0x000000018695a788 objc_exception_throw + 60
2 nsurlsessionhandler 0x0000000106d4562c xamarin_process_managed_exception + 1052
3 nsurlsessionhandler 0x00000001071a26c4 _ZL31native_to_managed_trampoline_53P11objc_objectP13objc_selectorPP11_MonoMethodS0_S0_S0_j + 1028
4 nsurlsessionhandler 0x00000001071ca8e0 -[System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate URLSession:dataTask:didReceiveData:] + 68
5 CFNetwork 0x000000018c0fe28c CFURLCredentialStorageCopyAllCredentials + 61900
6 libdispatch.dylib 0x0000000186b6c750 _dispatch_call_block_and_release + 32
7 libdispatch.dylib 0x0000000186b6e3e8 _dispatch_client_callout + 20
8 libdispatch.dylib 0x0000000186b75a14 _dispatch_lane_serial_drain + 748
9 libdispatch.dylib 0x0000000186b76578 _dispatch_lane_invoke + 432
10 libdispatch.dylib 0x0000000186b812d0 _dispatch_root_queue_drain_deferred_wlh + 288
11 libdispatch.dylib 0x0000000186b80b44 _dispatch_workloop_worker_thread + 404
12 libsystem_pthread.dylib 0x0000000186d1b00c _pthread_wqthread + 288
13 libsystem_pthread.dylib 0x0000000186d19d28 start_wqthread + 8
```
Disposing the CancellationTokenSource would be ideal, but the additional
complexity this would entail makes me question whether it's worth it: the
amount of entry points into this code makes it quite complex to keep track of
what the request has done, what it's doing and what's pending when things can
happen simultaneously on multiple threads at the same time, and keeping the
code thread-safe, and at the same time not accidentally not run into
deadlocks.
So it seems an easy fix would be to just not dispose the
CancellationTokenSource, the GC will eventually do it, even though MSDN
[says][1] quite clearly:
> Always call Dispose before you release your last reference to the CancellationTokenSource. Otherwise, the resources it is using will not be freed until the garbage collector calls the CancellationTokenSource object's Finalize method.
An additional note is that a network request's resource usage would already be
dwarfing any memory usage by the CancellationTokenSource, so it's unlikely
this will show up in any profiles.
So with this change we won't be disposing the CancellationTokenSource anymore.
Fixes https://github.com/xamarin/xamarin-macios/issues/11799.
[1]: https://learn.microsoft.com/en-us/dotnet/api/system.threading.cancellationtokensource.dispose?view=net-8.0
Fixes these warnings:
[API] API MISUSE: NSURLSession delegate System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate: <System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate: 0x600000676c60> (0x600000676c60)
[API] API MISUSE: dataTask:didReceiveResponse:completionHandler: completion handler not called
[API] API MISUSE: NSURLSession delegate System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate: <System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate: 0x600000676c60> (0x600000676c60)
[API] API MISUSE: dataTask:willCacheResponse:completionHandler: completion handler not called
[API] API MISUSE: NSURLSession delegate System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate: <System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate: 0x6000002cffa0> (0x6000002cffa0)
[API] API MISUSE: dataTask:willCacheResponse:completionHandler: completion handler not called
which is printed numerous times with the test case here:
https://github.com/xamarin/xamarin-macios/issues/11799#issuecomment-1988244584
This pull request updates the following dependencies
## From https://github.com/dotnet/xharness
- **Subscription**: 601bc5e1-1cae-44b5-cf5f-08db9342aa2f
- **Build**:
- **Date Produced**: March 18, 2024 11:58:47 AM UTC
- **Commit**: 2eb3ea9fc22aa1b51ff4221bafbeeebc42ef5979
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.DotNet.XHarness.iOS.Shared**: [from 9.0.0-prerelease.24160.7 to 9.0.0-prerelease.24168.1][1]
[1]: 36310c81ae...2eb3ea9fc2
The stack trace from unhandled exception is now:
Unhandled managed exception: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index') (System.ArgumentOutOfRangeException)
at System.Collections.Generic.List`1[[System.String, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].get_Item(Int32 index)
at CrashiOS.RootViewController.GetItem() in /Users/rolf/test/bugs/StackTraceIssue/CrashiOS/RootViewController.cs:line 19
at CrashiOS.RootViewController.<.ctor>b__1_0(Object _, EventArgs _) in /Users/rolf/test/bugs/StackTraceIssue/CrashiOS/RootViewController.cs:line 12
at UIKit.UIBarButtonItem.Callback.Call(NSObject sender) in xamarin-macios/src/UIKit/UIBarButtonItem.cs:line 33
--- End of stack trace from previous location ---
at ObjCRuntime.Runtime.ThrowException(IntPtr gchandle) in xamarin-macios/src/ObjCRuntime/Runtime.cs:line 2655
at UIKit.UIApplication.UIApplicationMain(Int32 argc, String[] argv, IntPtr principalClassName, IntPtr delegateClassName) in xamarin-macios/src/UIKit/UIApplication.cs:line 64
at UIKit.UIApplication.Main(String[] args, Type principalClass, Type delegateClass) in xamarin-macios/src/UIKit/UIApplication.cs:line 96
at Program.<Main>$(String[] args) in /Users/rolf/test/bugs/StackTraceIssue/CrashiOS/Main.cs:line 26
as opposed to:
Unhandled managed exception: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index') (System.ArgumentOutOfRangeException)
at ObjCRuntime.Runtime.ThrowException(IntPtr gchandle)
at UIKit.UIApplication.UIApplicationMain(Int32 argc, String[] argv, IntPtr principalClassName, IntPtr delegateClassName)
at UIKit.UIApplication.Main(String[] args, Type principalClass, Type delegateClass)
at Program.<Main>$(String[] args) in /Users/rolf/test/bugs/StackTraceIssue/CrashiOS/Main.cs:line 26
Fixes https://github.com/xamarin/xamarin-macios/issues/19417.
This also required a minor generator fix to fix generation of async methods
with a nullable NSError.
---------
Co-authored-by: Israel Soto <issoto@microsoft.com>
Make it appropriately quiet, and pass the project.
This makes the run-tests target work when there's also a .sln in the same
directory (which gets created automatically when opening the project in
VSCode).
* Enable generation of the documentation file (.xml) by the C# compiler when building projects (by passing the `DocumentationFlag` argument to the Csc task).
* Also disable the CSC1591 warning, which complains about having public APIs without xml documentation; it just turns out to be annoying rather than helpful, since most APIs won't be documented.
* Add support in the generator for reading the .xml file next to the compiled api definition assembly, and then looking for documentation there when generating binding code.
* When enabled, enable generation of the documentation file if the generator is compiling the api definitions.
* Make it an opt-out, in case the new code causes problems.
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/17397.
---------
Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>
Detect recursion when handling unhandled Objective-C exceptions, which can happen if:
* We install a handler for unhandled Objective-C exceptions.
* An unhandled Objective-C exception is caught.
* We convert the unhandled Objective-C exception to a managed exception, and throw that.
* Nobody handles the managed exception either, so we convert it to an Objective-C exception and throw that.
* We re-enter the unhandled Objective-C exception handler, and the cycle continues.
* Eventually the process crashes due to a stack overflow.
Fixes https://github.com/xamarin/xamarin-macios/issues/14796.
Per Apple docs for the `CGColorSpaceCreatePattern(CGColorSpaceRef
baseSpace)`, the `baseSpace` _should_ be null when creating the color
pattern. So, allow `null` here.
Fixes https://github.com/xamarin/xamarin-macios/issues/20293
Once upon a time we needed to special case a higher min OS version that the
min OS version we supported for certain compiler/linker arguments, because we
used features not supported in the min OS version we supported.
That time has passed; in all cases our min OS version is now higher than the
special-cased min OS versions passed to native compilers/linkers, so we can
just use the actual min OS version we support.
Rolf Bjarne Kvinge
Manuel de la Pena
Gerald Versluis
Michael Cummings (MSFT)
dotnet-maestro[bot]
Ryan Pendleton
Sergey Nechaev