fix: Crash on iOS with cupertino_http

[eseidel]

(internal link): https://admin.shorebird.dev/apps/bc6ee7bb-721d-464f-8075-215362b8f256/releases/168292

Symbolicated crash point:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000838
Exception Codes: 0x0000000000000001, 0x0000000000000838
VM Region Info: 0x838 is not in any region.  Bytes before following region: 4369217480
      REGION TYPE                 START - END      [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                   1046d0000-1046f4000 [  144K] r-x/r-x SM=COW  /var/containers/Bundle/Application/A8DEDB8E-37E5-48FB-A8B4-85815FEEAA95/ios_3.4.74+100_674341.app/Runner
Termination Reason: SIGNAL 11 Segmentation fault: 11
Terminating Process: exc handler [1026]

Thread 6:
0    Flutter                                  0x106b604dc dart::CallSimulatorFromFFI(unsigned long, unsigned long) (in Flutter) (shorebird_ffi_callback.cc:124)
1    ???                                      0x114fc4928 ???
2    cupertino_http                           0x1059754d4 ___NativeCupertinoHttp_wrapListenerBlock_1f43wec_block_invoke (in cupertino_http) (native_cupertino_bindings.m:178)
3    CoreFoundation                           0x18e69ce34 __invoking___
4    CoreFoundation                           0x18e69be7c -[NSInvocation invoke]
5    CoreFoundation                           0x18e6ffa38 -[NSInvocation invokeWithTarget:]
6    objective_c                              0x105e75a10 -[DartProxy forwardInvocation:] (in objective_c) (proxy.m:90)
7    CoreFoundation                           0x18e69d374 ___forwarding___
8    CoreFoundation                           0x18e69cef0 _CF_forwarding_prep_0
9    CFNetwork                                0x18fbcf06c __81-[__NSCFURLSessionDelegateWrapper dataTask:didReceiveResponse:completionHandler:]_block_invoke
10   Foundation                               0x18d2ccc9c __NSINDEXSET_IS_CALLING_OUT_TO_A_BOOL_BLOCK__
11   Foundation                               0x18d2bc568 -[NSBlockOperation main]
12   Foundation                               0x18d2bc488 __NSOPERATION_IS_INVOKING_MAIN__
13   Foundation                               0x18d2ba8e0 -[NSOperation start]
14   Foundation                               0x18d2f1ce0 __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__
15   Foundation                               0x18d2f1910 __NSOQSchedule_f
16   libdispatch.dylib                        0x19643a394 _dispatch_block_async_invoke2
17   libdispatch.dylib                        0x19642afa8 _dispatch_client_callout
18   libdispatch.dylib                        0x19642e45c _dispatch_continuation_pop
19   libdispatch.dylib                        0x19642da8c _dispatch_async_redirect_invoke
20   libdispatch.dylib                        0x19643cec0 _dispatch_root_queue_drain
21   libdispatch.dylib                        0x19643d6c4 _dispatch_worker_thread2
22   libsystem_pthread.dylib                  0x2193b0644 _pthread_wqthread
23   libsystem_pthread.dylib                  0x2193ae474 start_wqthread

I believe what is going on is that cupertino_http is calling back into Dart via ffi, possibly via an async ffi callback, and we're not guarding against the case where the Dart Isolate has stopped at that point.

https://github.com/dart-lang/sdk/blob/949eb447a47b49f6db18c7920a0de837b274757b/runtime/vm/compiler/stub_code_compiler_arm64.cc#L587 appears to be how upstream guards this case.

But we wrap that stub with our own and I don't see us checking if the isolate has stopped or the thread is null, etc, and instead just try to get the simulator off the thread which ends up with a low value invalid pointer.

My bet is that if we checked 0x0000000000000838 that would be exactly the value of the Simulator thread offset, thus THR is just null at this point.

Should be a simple fix, the only question is getting a repro (ideally that runs in our Dart vm tests).

[eseidel]

Felix looked at this in detail today. We were able to reproduce. We know how we're going to fix this, but it will take several days of work, and is currently delayed by other pressing work. We'll update this bug as we know more.

The good news is that the fix here will actually make all Flutter apps using Shorebird on iOS a little faster. :) (Our dart:ffi support in Shorebird was written before dart:ffi async support existed, and although we though we had made dart:ffi async work, we clearly missed a case which will require a significant refactor of our ffi support to fix correctly.)