App crash due to NullReferenceException in NSUrlSessionHandlerDelegate.DidCompleteWithError

[adams-family]

IMPORTANT:

I think this problem will be somewhat related to: https://github.com/xamarin/xamarin-macios/issues/9132

Steps to Reproduce

I happens on iOS, latest versions (latest iOS, latest Xamarin) very often in production (tens of crashes per day on a 2k user basis), randomly. It's hard to reproduce it in the debugger.

protected HttpClient client = new HttpClient();

void Test()
{
  try
  {
     var stringContent = new StringContent(json, UnicodeEncoding.UTF8, "application/json");
     stringContent.Headers.Add("sample", "value");
     var response = await client.PostAsync("https://....", stringContent);
  }
  catch (Exception e)
  {
     // it never hits this exception handler
  }
}

Expected Behavior

Thanks to the try/catch block this code should never cause an app crash.

Actual Behavior

The app crashes. Here is an AppCenter stacktrace:

NSUrlSessionHandler+NSUrlSessionHandlerDelegate.DidCompleteWithError (Foundation.NSUrlSession session, Foundation.NSUrlSessionTask task, Foundation.NSError error)

Environment

Microsoft Visual Studio Community 2019
Version 16.8.4
VisualStudio.16.Release/16.8.4+30907.101
Microsoft .NET Framework
Version 4.8.04084

Installed Version: Community

Visual C++ 2019   00435-60000-00000-AA591
Microsoft Visual C++ 2019

ASP.NET and Web Tools 2019   16.8.557.25636
ASP.NET and Web Tools 2019

Azure App Service Tools v3.0.0   16.8.557.25636
Azure App Service Tools v3.0.0

C# Tools   3.8.0-5.20604.10+9ed4b774d20940880de8df1ca8b07508aa01c8cd
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Common Azure Tools   1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Extensibility Message Bus   1.2.6 (master@34d6af2)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.

IncrediBuild Build Acceleration   1.5.0.13
IncrediBuild effectively reduces compilation and development times by up to 90%.

IntelliCode Extension   1.0
IntelliCode Visual Studio Extension Detailed Info

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Microsoft MI-Based Debugger   1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Microsoft Visual C++ Wizards   1.0
Microsoft Visual C++ Wizards

Microsoft Visual Studio VC Package   1.0
Microsoft Visual Studio VC Package

Mono Debugging for Visual Studio   16.8.43 (00471f8)
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager   5.8.1
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

ProjectServicesPackage Extension   1.0
ProjectServicesPackage Visual Studio Extension Detailed Info

Qt Visual Studio Tools   2.7.1.18
The Qt Visual Studio Tools allow developers to use the standard development environment without having to worry about any Qt-related build steps or tools.

Syncfusion ASP.NET Core Project Templates   18.1.0.42
Provides project templates for creating an ASP.NET Core Web Application using Syncfusion ASP.NET Core components.

Syncfusion ASP.NET Core Project Templates   16.1.0.32
Provides project templates for creating an ASP.NET Core Web Application using Syncfusion ASP.NET Core components.

Syncfusion ASP.NET MVC Project Templates   17.1.0.32
Provides project templates for creating ASP.NET MVC Web Applications using Syncfusion components.

Syncfusion Xamarin Project Templates   13.4.0.53
A multi-project template for building iOS, Android, and Windows apps using Syncfusion Xamarin components.

Syncfusion Xamarin Toolbox   16.2.0.19
Syncfusion Essential Studio for Xamarin Toolbox Visual Studio extension.

SyncfusionMenu Extension   1.0
SyncfusionMenu Visual Studio Extension Detailed Info

Test Adapter for Boost.Test   1.0
Enables Visual Studio's testing tools with unit tests written for Boost.Test.  The use terms and Third Party Notices are available in the extension installation directory.

Test Adapter for Google Test   1.0
Enables Visual Studio's testing tools with unit tests written for Google Test.  The use terms and Third Party Notices are available in the extension installation directory.

Visual Basic Tools   3.8.0-5.20604.10+9ed4b774d20940880de8df1ca8b07508aa01c8cd
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools   16.8.0-beta.20507.4+da6be68280c89131cdba2045525b80890401defd
Microsoft Visual F# Tools

Visual Studio Code Debug Adapter Host Package   1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

Visual Studio Tools for CMake   1.0
Visual Studio Tools for CMake

VisualStudio.DeviceLog   1.0
Information about my package

VisualStudio.Foo   1.0
Information about my package

VisualStudio.Mac   1.0
Mac Extension for Visual Studio

Xamarin   16.8.000.261 (d16-8@bb99248)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer   16.8.0.507 (remotes/origin/d16-8@e87b24884)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Templates   16.8.112 (86385a3)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK   11.1.0.26 (d16-8/a36ce73)
Xamarin.Android Reference Assemblies and MSBuild support.
    Mono: 5e9cb6d
    Java.Interop: xamarin/java.interop/d16-8@79d9533
    ProGuard: Guardsquare/proguard/proguard6.2.2@ebe9000
    SQLite: xamarin/sqlite/3.32.1@1a3276b
    Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-8@2fb1cbc

Xamarin.iOS and Xamarin.Mac SDK   14.8.0.3 (c51fabee8)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

Example Project (If Possible)

I don't think it's possible to create one because I'd need to roll it out to at least a thousand users.

[hjharvey-MSFT]

@hjharvey-MSFT i cannot give you an update cause i am waiting for Xamarin.iOS 15 installer package, which is not available for download anymore @rolfbjarne mentioned he was building something on top of Xamarin.iOS 15, but haven't anything

@narciszait Any updates? I am eagerly awaiting to hear about the outcome for this test.

[narciszait]

@hjharvey-MSFT we released last night our beta version to beta testers and are monitoring. I will come back with news on Monday - if that is ok for you - want to let it run over the weekend and keep an eye out

[hjharvey-MSFT]

@hjharvey-MSFT we released last night our beta version to beta testers and are monitoring. I will come back with news on Monday - if that is ok for you - want to let it run over the weekend and keep an eye out

How did the testing go @narciszait? --Fixed Tag :)

[narciszait]

@hjharvey-MSFT from a userbase of 800+ users, we got 9 crashes over a one week period of time. and this time, the crashes point to the same place, not different NSURLDelegate methods

Will keep an eye out and come back at the end of next week with some updates. After that I will on holiday until the first week of March.

PS: You tagged the wrong Narcis person in your previous message :)

[hjharvey-MSFT]

@

@hjharvey-MSFT from a userbase of 800+ users, we got 9 crashes over a one week period of time. and this time, the crashes point to the same place, not different NSURLDelegate methods

Will keep an eye out and come back at the end of next week with some updates. After that I will on holiday until the first week of March.

PS: You tagged the wrong Narcis person in your previous message :)

Is this an improvement over previous versions?

[narciszait]

@hjharvey-MSFT i would say yes - even through the beta phase we saw higher numbers and pointing to different NSURLSession methods. If the time allows it, i will return with more numbers next week

[tipa]

I am also seeing a ton of app crashes after migrating to .NET7 and doing concurrent network requests. Stack traces look a bit different (I am also using AppCenter, not Sentry). I also reported this here. Might be the same bug despite the different stack traces? Has anyone figured out a way to reduce the impact of this? Perhaps running the network requests serially or something?

Edit: was able to extract this data out of one stack trace, maybe it contains and useful info:

Thread 6 name:  .NET ThreadPool Worker
Thread 6:
0   MyApp.iOS                              0x1044c783c mono_seq_point_iterator_next + 25327676 (seq-points-data.c:303)
1   MyApp.iOS                              0x1044c7ad0 mono_seq_point_find_prev_by_native_offset + 25328336 (seq-points-data.c:243)
2   MyApp.iOS                              0x10458a424 mono_walk_stack_full + 26125348 (mini-exceptions.c:0)
3   MyApp.iOS                              0x10458cda0 mono_handle_native_crash + 26135968 (mini-exceptions.c:3016)
4   MyApp.iOS                              0x10456a49c mono_sigsegv_signal_handler_debug + 25994396 (mini-runtime.c:0)
5   libsystem_platform.dylib               0x1f60aba90 _sigtramp + 56
6   MyApp.iOS                              0x1045722a4 mini_init_method_rgctx + 26026660 (jit-icalls.c:1681)
7   MyApp.iOS                              0x103dea86c corlib_System_Runtime_InteropServices_MemoryMarshal_TryGetArray_T_BYTE_System_ReadOnlyMemory_1_T_BYTE_System_ArraySegment_1_T_BYTE_ + 92
8   MyApp.iOS                              0x103024c88 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 296
9   MyApp.iOS                              0x10456d558 mono_jit_runtime_invoke + 26006872 (mini-runtime.c:3525)
10  MyApp.iOS                              0x1044ac07c mono_runtime_invoke_checked + 25215100 (object.c:2583)
11  MyApp.iOS                              0x104571b6c mono_gsharedvt_constrained_call + 26024812 (jit-icalls.c:1477)
12  MyApp.iOS                              0x1030294c8 wrapper_managed_to_native_object___icall_wrapper_mono_gsharedvt_constrained_call_intptr_intptr_intptr_intptr_intptr + 152
13  MyApp.iOS                              0x102fe9674 System_Runtime_CompilerServices_AsyncMethodBuilderCore_Start_TStateMachine_GSHAREDVT_TStateMachine_GSHAREDVT_ + 372
14  MyApp.iOS                              0x103da2a30 corlib_System_IO_Stream__CopyToAsyncg__Core_27_0_System_IO_Stream_System_IO_Stream_int_System_Threading_CancellationToken + 172
15  MyApp.iOS                              0x102e26d78 System_Net_Http_HttpClient___SendAsyncg__Core_83_0d_MoveNext + 1600888 (/<unknown>:1)
16  MyApp.iOS                              0x1035a12c4 System_Net_Http_System_Runtime_CompilerServices_AsyncTaskMethodBuilder_1_AsyncStateMachineBox_1_System_Net_Http_HttpResponseMessage_System_Net_Http_HttpClient___SendAsyncg__Core_83_0d_ExecutionContextCallback_object + 56
17  MyApp.iOS                              0x103d40f58 corlib_System_Threading_Tasks_Task_RunContinuations_object + 276
18  MyApp.iOS                              0x103d40df4 corlib_System_Threading_Tasks_Task_FinishContinuations + 124
19  MyApp.iOS                              0x103344698 Microsoft_iOS_System_Runtime_CompilerServices_AsyncTaskMethodBuilder_1_AsyncStateMachineBox_1_System_Net_Http_HttpResponseMessage_System_Net_Http_NSUrlSessionHandler__SendAsyncd__58_ExecutionContextCallback_object + 56
20  MyApp.iOS                              0x103d40f58 corlib_System_Threading_Tasks_Task_RunContinuations_object + 276
21  MyApp.iOS                              0x103d40df4 corlib_System_Threading_Tasks_Task_FinishContinuations + 124
22  MyApp.iOS                              0x103d3f74c corlib_System_Threading_Tasks_Task_ExecuteEntryUnsafe_System_Threading_Thread + 164
23  MyApp.iOS                              0x103d14bc8 corlib_System_Threading_Thread_StartCallback + 256
24  MyApp.iOS                              0x10456d558 mono_jit_runtime_invoke + 26006872 (mini-runtime.c:3525)
25  MyApp.iOS                              0x1044ac07c mono_runtime_invoke_checked + 25215100 (object.c:2583)
26  MyApp.iOS                              0x1044c5bd0 start_wrapper_internal + 25320400 (threads.c:1215)
27  MyApp.iOS                              0x1044c5960 start_wrapper + 25319776 (threads.c:1266)
28  libsystem_pthread.dylib                0x1f61416cc _pthread_start + 148

[narciszait]

@hjharvey-MSFT having a look in Xcode for crashes, we got 2 reports for NSURLSessionDelegateWrapper, one with 9 crashes and the other one with23 Will have a look at our other tool and let you know.

[dalexsoto]

Unfortunately with the current information we have there is really not a good idea on the why this is happening. We would need a way to reproduce this issue in order to continue investigating this.

[narciszait]

On one of the referenced issues that is closed, i commented about triggering this crash by hitting a breakpoint where i was making a network request and letting it stay on the breakpoint for some time. When i resumed, it crashed - i suspect it was a timeout on the network call. I can dig out the comment if you want

[narciszait]

I am doing some symbolication at the moment and i keep seeing this line: System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate_DidCompleteWithError_Foundation_NSUrlSession_Foundation_NSUrlSessionTask_Foundation_NSError + 27411356 (NSUrlSessionHandler.cs:770) if it is of any help

[hjharvey-MSFT]

@narciszait would you be able to provide a sample and instructions on how to repro the issue?

[narciszait]

@hjharvey-MSFT unfortunately no - i have no idea on how to reproduce it, hence i cannot make a sample.

Like i said, i managed once in a blue moon to get the crash when hitting a breakpoint where i was making a network request and letting it stay on the breakpoint for some time. When i resumed, it crashed - i suspect it was a timeout on the network call.

[miszu]

We are seeing this crash from time to time as well, I think it happens in cases when the app was in the background for a long time.

Info.plist:

<key>com.microsoft.ios</key>
<dict>
<key>Version</key>
<string>16.4.7089+sha.663e05acb</string>
</dict>

Crash from AppCenter:

Application Specific Information:
*** Terminating app due to uncaught exception 'SIGABRT', reason: 'CancellationTokenSource_Disposed'

Xamarin Exception Stack:
System.ObjectDisposedException: CancellationTokenSource_Disposed
  at System.ThrowHelper.ThrowObjectDisposedException ()
  at System.Threading.CancellationTokenSource.ThrowIfDisposed ()
  at System.Threading.CancellationTokenSource.Cancel ()
  at System.Threading.CancellationTokenSource.Cancel ()
  at System.Net.Http.NSUrlSessionHandler+NSUrlSessionHandlerDelegate.DidCompleteWithError ()

Thread 11 Crashed:
0   libsystem_kernel.dylib               0x00000002048f1578 __pthread_kill + 8
1   libsystem_c.dylib                    0x00000001cd75c178 abort + 176
2   <redacted_appname>               0x0000000102c8b3c8 xamarin_unhandled_exception_handler (runtime.m:1126)
3   <redacted_appname>               0x0000000102e64f44 mono_invoke_unhandled_exception_hook (exception.c:1219)
4    <redacted_appname>               0x0000000102f89128 mono_handle_exception_internal (mini-exceptions.c:2326)
5   <redacted_appname>               0x0000000102f87684 mono_handle_exception (mini-exceptions.c:2668)
6    <redacted_appname>               0x0000000102f9e1f0 mono_arm_throw_exception (exceptions-arm64.c:402)
7    <redacted_appname>               0x0000000102c6430c throw_exception + 168
8   <redacted_appname>               0x0000000102eb5384 mono_raise_exception (object.c:7409)
9    <redacted_appname>               0x0000000102c8b0dc xamarin_process_managed_exception (runtime.m:2360)
10   <redacted_appname>               0x00000001030607e0 native_to_managed_trampoline_11(objc_object*, objc_selector*, _MonoMethod**, objc_object*, objc_object*, objc_object*, unsigned int) (registrar.mm:736)
11  <redacted_appname>               0x000000010309cb70 -[System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate URLSession:task:didCompleteWithError:] (registrar.mm:25370)
12  CFNetwork                            0x00000001c725ad0c CFURLRequestCopyHTTPRequestMethod + 2268
13  libdispatch.dylib                    0x00000001cd6fa320 _dispatch_call_block_and_release + 28
14  libdispatch.dylib                    0x00000001cd6fbeac _dispatch_client_callout + 16
15  libdispatch.dylib                    0x00000001cd703534 _dispatch_lane_serial_drain + 664
16  libdispatch.dylib                    0x00000001cd7040d8 _dispatch_lane_invoke + 432
17  libdispatch.dylib                    0x00000001cd70ecdc _dispatch_workloop_worker_thread + 644
18  libsystem_pthread.dylib              0x00000002255f2ddc _pthread_wqthread + 284
19  libsystem_pthread.dylib              0x00000002255f2b7c start_wqthread + 4

[TimofeyBurak]

We are also seeing crash reports with the same stack trace in AppCenter:

CancellationTokenSource.ThrowObjectDisposedException ()
CancellationTokenSource.ThrowIfDisposed ()
CancellationTokenSource.Cancel ()
NSUrlSessionHandler+NSUrlSessionHandlerDelegate.DidCompleteWithError (Foundation.NSUrlSession session, Foundation.NSUrlSessionTask task, Foundation.NSError error)

This issue might be hard to reproduce because it requires very precise timings, but I have a theory about possible root cause:

https://github.com/xamarin/xamarin-macios/blob/net8.0/src/Foundation/NSUrlSessionHandler.cs#L930-L957

According to the source code of the DidCompleteWithError(...) method, there's a short period of time between inflight data being obtained (line 933) and cancellation being called (line 941). If the same inflight data is removed somewhere between those two points - it will be already disposed by the line 941, thus causing ObjectDisposedException being thrown.

Inflight data is removed whenever original managed request is cancelled:

https://github.com/xamarin/xamarin-macios/blob/net8.0/src/Foundation/NSUrlSessionHandler.cs#L527-L542

So, one of possible reproduction scenarios is following: original managed request is being cancelled shortly after DidCompleteWithError(...) callback is called. @hjharvey-MSFT @dalexsoto can you check if this might be the cause of the issue, please?

[csnellemann]

@hjharvey-MSFT any update on this, given the hypothesis from @TimofeyBurak above?

[kmiterror]

This is still a thing, we are getting tons of those after updating to net7. We changed default HttpClient implementation to use HttpClient (managed) handler, but it seems that one of our sub-dependencies doesn't respect that setting.

[tipa]

I was able to reproduce the crash locally 4 times within just a couple of minutes using this example: nsurlsessionhandler.zip

2024-03-11 12:14:44.122321+0100 nsurlsessionhandler[15973:365565] *** Terminating app due to uncaught exception 'System.ObjectDisposedException', reason: 'The CancellationTokenSource has been disposed. (System.ObjectDisposedException)
   at System.Threading.CancellationTokenSource.ThrowIfDisposed()
   at System.Threading.CancellationTokenSource.get_Token()
   at System.Net.Http.NSUrlSessionHandler.NSUrlSessionHandlerDelegate.SetResponse(InflightData inflight) in /Users/builder/azdo/_work/1/s/xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:line 965
   at System.Net.Http.NSUrlSessionHandler.NSUrlSessionHandlerDelegate.DidReceiveData(NSUrlSession session, NSUrlSessionDataTask dataTask, NSData data) in /Users/builder/azdo/_work/1/s/xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:line 927
'
*** First throw call stack:
(
    0   CoreFoundation                      0x000000010ea86761 __exceptionPreprocess + 242
    1   libobjc.A.dylib                     0x000000011ef2e904 objc_exception_throw + 48
    2   libxamarin-dotnet-debug.dylib       0x0000000109eb9016 xamarin_process_ma
*** Terminating app due to uncaught exception 'System.ObjectDisposedException', reason: 'The CancellationTokenSource has been disposed. (System.ObjectDisposedException)
   at System.Threading.CancellationTokenSource.ThrowIfDisposed()
   at System.Threading.CancellationTokenSource.get_Token()
   at System.Net.Http.NSUrlSessionHandler.NSUrlSessionHandlerDelegate.SetResponse(InflightData inflight) in /Users/builder/azdo/_work/1/s/xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:line 965
   at System.Net.Http.NSUrlSessionHandler.NSUrlSessionHandlerDelegate.DidReceiveData(NSUrlSession session, NSUrlSessionDataTask dataTask, NSData data) in /Users/builder/azdo/_work/1/s/xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:line 927
'
*** First throw call stack:
(
    0   CoreFoundation                      0x000000010ea86761 __exceptionPreprocess + 242
    1   libobjc.A.dylib                     0x000000011ef2e904 objc_exception_throw + 48
    2   libxamarin-dotnet-debug.dylib       0x0000000109eb9016 xamarin_process_managed_exception + 934
    3   nsurlsessionhandler                 0x000000010014ed67 _ZL31native_to_managed_trampoline_59P11objc_objectP13objc_selectorPP11_MonoMethodS0_S0_S0_j + 1143
    4   nsurlsessionhandler                 0x0000000100176713 -[System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate URLSession:dataTask:didReceiveData:] + 67
    5   CFNetwork                           0x000000010bd4ea69 CFNetwork + 72297
    6   libdispatch.dylib                   0x000000011f39ca90 _dispatch_call_block_and_release + 12
    7   libdispatch.dylib                   0x000000011f39dd3a _dispatch_client_callout + 8
    8   libdispatch.dylib                   0x000000011f3a585c _dispatch_lane_serial_drain + 1236
    9   libdispatch.dylib                   0x000000011f3a63f7 _dispatch_lane_invoke + 406
    10  libdispatch.dylib                   0x000000011f3b1fac _dispatch_root_queue_drain_deferred_wlh + 276
    11  libdispatch.dylib                   0x000000011f3b1572 _dispatch_workloop_worker_thread + 552
    12  libsystem_pthread.dylib             0x0000000120341c47 _pthread_wqthread + 327
    13  libsystem_pthread.dylib             0x0000000120340b97 start_wqthread + 15

I also noticed several of those logs, which appear to be unrelated, but perhaps should be addressed as well:

2024-03-11 12:15:58.090531+0100 nsurlsessionhandler[16022:367058] [API] API MISUSE: NSURLSession delegate System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate: <System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate: 0x600000c05d20> (0x600000c05d20)
2024-03-11 12:15:58.092269+0100 nsurlsessionhandler[16022:367058] [API] API MISUSE: dataTask:didReceiveResponse:completionHandler: completion handler not called

[rolfbjarne]

I was able to reproduce the crash locally 4 times within just a couple of minutes using this example:

I can reproduce crashes too. I'll have a look.

[rolfbjarne]

It seems this is the sequence of events for the ObjectDisposedException:

1. The request is sent.
2. The request is cancelled.
3. The InflightData instance is removed here: https://github.com/xamarin/xamarin-macios/blob/c3437328bf2c02d03a6d4dc4e752ef8ac927ca4e/src/Foundation/NSUrlSessionHandler.cs#L545 3a. The InflightData is disposed: https://github.com/xamarin/xamarin-macios/blob/c3437328bf2c02d03a6d4dc4e752ef8ac927ca4e/src/Foundation/NSUrlSessionHandler.cs#L224 3a. The InflightData.CancellationTokenSource instance is disposed: https://github.com/xamarin/xamarin-macios/blob/c3437328bf2c02d03a6d4dc4e752ef8ac927ca4e/src/Foundation/NSUrlSessionHandler.cs#L1168
4. Data comes in (in the DidReceiveData callback), and SetResponse is called: https://github.com/xamarin/xamarin-macios/blob/c3437328bf2c02d03a6d4dc4e752ef8ac927ca4e/src/Foundation/NSUrlSessionHandler.cs#L932 4a. The SetResponse method tries to use InflightData.CancellationTokenSource, and that throws an ObjectDisposedException: https://github.com/xamarin/xamarin-macios/blob/c3437328bf2c02d03a6d4dc4e752ef8ac927ca4e/src/Foundation/NSUrlSessionHandler.cs#L970

Full stack traces:

Inflight 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

@mandel-macaque it seems an easy fix would be to just not dispose the CancellationTokenSource, the GC will eventually do it.

Although MSDN says 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.

The amount of entry points into this code makes it quite complex to keep it thread-safe, while at the same time not accidentally not run into deadlocks. While disposing the CancellationTokenSource would be ideal, the additional complexity this would entail makes me question whether it's worth it.

[rolfbjarne]

I also noticed several of those logs, which appear to be unrelated, but perhaps should be addressed as well:

2024-03-11 12:15:58.090531+0100 nsurlsessionhandler[16022:367058] [API] API MISUSE: NSURLSession delegate System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate: <System_Net_Http_NSUrlSessionHandler_NSUrlSessionHandlerDelegate: 0x600000c05d20> (0x600000c05d20)
2024-03-11 12:15:58.092269+0100 nsurlsessionhandler[16022:367058] [API] API MISUSE: dataTask:didReceiveResponse:completionHandler: completion handler not called

Fix in progress: https://github.com/xamarin/xamarin-macios/pull/20326.

[kmiterror]

@rolfbjarne Is this going to be backported to dotnet8?

[rolfbjarne]

@rolfbjarne Is this going to be backported to dotnet8?

The networking code is rather sensitive, in that any changes has a high potential for breaking someone. Coupled with the fact that these changes weren't entirely trivial, at the moment we're leaning towards not backporting them to .NET 8.

However, these changes are included in .NET 9 preview 3, so if you want to try the preview, and see if your issues are fixed, then that would be great (and a successful test might also make us reconsider backporting the fixes).