cupertino_http 2.4.0 crashes on iOS on wrapListenerBlock

[orestesgaolin]

Typically user leaves the app and it crashes with the following stacktrace:

SIGABRT: ZTUM
  libsystem_kernel    0x1d79981dc  __pthread_kill
  libsystem_pthread   0x210fe3c18  pthread_kill
  libsystem_c         0x18eb23050  abort
  Flutter             0x10ae56c9c  dart::Assert::Fail (assert.cc:54)
  Flutter             0x10af104dc  DLRT_GetFfiCallbackMetadata (runtime_entry.cc:5144)
  0x114945d10  <redacted>
  cupertino_http      0x10982c34c  ___NativeCupertinoHttp_wrapListenerBlock_xx612k_block_invoke (native_cupertino_bindings.m:534)
  cupertino_http      0x10982c34c  ___NativeCupertinoHttp_wrapListenerBlock_xx612k_block_invoke (native_cupertino_bindings.m:534)
  cupertino_http      0x10982c758  _NativeCupertinoHttp_protocolTrampoline_xx612k (native_cupertino_bindings.m:555)
  CFNetwork           0x18809b2e8  __81-[__NSCFURLSessionDelegateWrapper dataTask:didReceiveResponse:completionHandler:]_block_invoke
  Foundation          0x18576543c  __NSINDEXSET_IS_CALLING_OUT_TO_A_BOOL_BLOCK__
  Foundation          0x18579be2c  -[NSBlockOperation main]
  Foundation          0x18579b570  __NSOPERATION_IS_INVOKING_MAIN__
  Foundation          0x18579b7f8  -[NSOperation start]
  Foundation          0x18579bbac  __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__
  Foundation          0x18579d1c8  __NSOQSchedule_f
  libdispatch         0x18ea772b4  _dispatch_block_async_invoke2
  libdispatch         0x18ea81580  _dispatch_client_callout
  libdispatch         0x18ea6c55c  _dispatch_continuation_pop
  libdispatch         0x18ea6bbd0  _dispatch_async_redirect_invoke
  libdispatch         0x18ea79dac  _dispatch_root_queue_drain
  libdispatch         0x18ea7a548  _dispatch_worker_thread2
  libsystem_pthread   0x210fdc9cc  _pthread_wqthread

  libsystem_kernel    0x1d79981dc  __pthread_kill
  libsystem_pthread   0x210fe3c18  pthread_kill
  libsystem_c         0x18eb23050  abort
  Flutter             0x10ae56c9c  dart::Assert::Fail (assert.cc:54)
  Flutter             0x10af104dc  DLRT_GetFfiCallbackMetadata (runtime_entry.cc:5144)
  0x114945d10  <redacted>
  cupertino_http      0x10982c34c  ___NativeCupertinoHttp_wrapListenerBlock_xx612k_block_invoke (native_cupertino_bindings.m:534)
  cupertino_http      0x10982c34c  ___NativeCupertinoHttp_wrapListenerBlock_xx612k_block_invoke (native_cupertino_bindings.m:534)
  cupertino_http      0x10982c758  _NativeCupertinoHttp_protocolTrampoline_xx612k (native_cupertino_bindings.m:555)
  CFNetwork           0x18809b2e8  __81-[__NSCFURLSessionDelegateWrapper dataTask:didReceiveResponse:completionHandler:]_block_invoke
  Foundation          0x18576543c  __NSINDEXSET_IS_CALLING_OUT_TO_A_BOOL_BLOCK__
  Foundation          0x18579be2c  -[NSBlockOperation main]
  Foundation          0x18579b570  __NSOPERATION_IS_INVOKING_MAIN__
  Foundation          0x18579b7f8  -[NSOperation start]
  Foundation          0x18579bbac  __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__
  Foundation          0x18579d1c8  __NSOQSchedule_f
  libdispatch         0x18ea772b4  _dispatch_block_async_invoke2
  libdispatch         0x18ea81580  _dispatch_client_callout
  libdispatch         0x18ea6c55c  _dispatch_continuation_pop
  libdispatch         0x18ea6bbd0  _dispatch_async_redirect_invoke
  libdispatch         0x18ea79dac  _dispatch_root_queue_drain
  libdispatch         0x18ea7a548  _dispatch_worker_thread2
  libsystem_pthread   0x210fdc9cc  _pthread_wqthread

flutter doctor

[✓] Flutter (Channel stable, 3.38.4, on macOS 15.6.1 24G90 darwin-arm64, locale pl-PL) [435ms]
    • Flutter version 3.38.4 on channel stable at /Users/dominik/fvm/versions/3.38.4
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 66dd93f9a2 (3 months ago), 2025-12-03 14:56:10 -0800
    • Engine revision a5cb96369e
    • Dart version 3.10.3
    • DevTools version 2.51.1
    • Feature flags: enable-web, no-enable-linux-desktop, enable-macos-desktop, no-enable-windows-desktop, enable-android,
      enable-ios, cli-animations, enable-native-assets, omit-legacy-version-file, enable-lldb-debugging

[!] Android toolchain - develop for Android devices (Android SDK version 36.1.0) [6,3s]
    • Android SDK at /Users/dominik/Library/Android/sdk
    • Emulator version 36.4.10.0 (build_id 15004761) (CL:N/A)
    ✗ cmdline-tools component is missing.
      Try installing or updating Android Studio.
      Alternatively, download the tools from https://developer.android.com/studio#command-line-tools-only and make sure to
      set the ANDROID_HOME environment variable.
      See https://developer.android.com/studio/command-line for more details.
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/to/macos-android-setup for more details.

[✓] Xcode - develop for iOS and macOS (Xcode 26.3) [1 370ms]
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 17C529
    • CocoaPods version 1.16.2

[✓] Chrome - develop for the web [6ms]
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Connected device (4 available) [10,2s]
    • SM S911B (mobile)          • RFCW60DP85H               • android-arm64  • Android 16 (API 36)
    • iPhone (wireless) (mobile) • 00008101-0001510C3CF0001E • ios            • iOS 26.3.1 23D8133
    • macOS (desktop)            • macos                     • darwin-arm64   • macOS 15.6.1 24G90 darwin-arm64
    • Chrome (web)               • chrome                    • web-javascript • Google Chrome 146.0.7680.80

[✓] Network resources [252ms]
    • All expected network resources are available.

! Doctor found issues in 1 category.

Dependencies

deps.txt

• issue occurs across wide range of iOS versions
• issue seems to occur after moving the app to the background after successful HTTP requests - 99%+ issues occur when app is not in the foreground according to Sentry

[mraleph]

I think it is quite likely the same issue that was reported flutter/flutter#182996 - callbacks still fire but underlying isolate went away.

I would guess this is related to the code here

http/pkgs/cupertino_http/lib/src/cupertino_api.dart

Lines 1119 to 1121 in 8660fa7

	final queue = ncb.NSOperationQueue()
	..maxConcurrentOperationCount = 1
	..name = 'cupertino_http.NSURLSessionDelegateQueue'.toNSString();

which creates NSOperationQueue. When isolate goes away - we will release the queue, via native finalizer, but I think that might not be enough to stop the queue from running. You need to call cancelAllOperations and waitUntilAllOperationsAreFinished to avoid any sort of races between isolate going away and callbacks firing from the queue.

[orestesgaolin]

Thank you for linking this back. I'm happy to run a test with our beta users as soon as there's tentative/speculative fix.

[brianquinlan]

@liamappelbe

Is there a way that cupertino_http could guard against this in general? For example:

import 'dart:async';
import 'dart:io';
import 'dart:isolate';
import 'package:cupertino_http/cupertino_http.dart';

void main() async {
  final server = await HttpServer.bind('localhost', 0);
  server.listen((request) async {
    await Future.delayed(const Duration(milliseconds: 500));
    request.response.write('Hello');
    await request.response.close();
  });

  print('Server listening on ${server.port}');
  final uri = Uri.parse('http://localhost:${server.port}');

  for (int i = 0; i < 100; ++i) {
    print('Iteration $i');
    unawaited(Isolate.run(() {
      final config = URLSessionConfiguration.defaultSessionConfiguration();
      final session = URLSession.sessionWithConfiguration(config,
        // `onComplete` will be triggered after the Isolate exits
        onComplete: (s, t, e) => print('Should not see this')
      );
      final task = session.dataTaskWithRequest(URLRequest.fromUrl(uri));
      task.resume();
      // Isolate finishes and shuts down here, while task is in flight.
    }));
    await Future.delayed(const Duration(milliseconds: 50));
  }

  print('Waiting for native crashes...');
  await Future.delayed(const Duration(seconds: 5));
  await server.close();
}

± dart run repro_with_classes.dart
Running build hooks...
Server listening on 57152
Iteration 0
Iteration 1
Iteration 2
Iteration 3
Iteration 4
Iteration 5
Iteration 6
Iteration 7
Iteration 8
Iteration 9
Iteration 10
Iteration 11
Iteration 12
../../runtime/vm/runtime_entry.cc: 5122: error: Callback invoked after it has been deleted.
version=3.11.2 (stable) (Tue Mar 10 01:02:11 2026 -0700) on "macos_arm64"
pid=95365, thread=19971, isolate_group=(nil)(0x0), isolate=(nil)(0x0)
os=macos, arch=arm64, comp=no, sim=no
isolate_instructions=0, vm_instructions=10082ce20
fp=170656a20, sp=1706569f0, pc=100ad0bd4
../../runtime/vm/runtime_entry.cc: 5122: error: Callback invoked after it has been deleted.
Aborting reentrant request for stack trace.
Abort trap: 6

Where could cupertino_http inject logic to prevent onComplete from running? AFAIK, there is no way for Dart code to be informed when its Isolate is exiting (unless you control Isolate creation). Could I write some native code, that is triggered by a native finalizer when URLSession is collected, that invalidates the wrapped NSURLSession?

For CupertinoClient, I can change the close method like:

  @override
  void close() {
-    _urlSession?.finishTasksAndInvalidate();
+    _urlSession?.invalidateAndCancel(); 
    _urlSession = null;
  }

But that will still lead to a crash if the developer doesn't call close or in the hot restart case described in flutter/flutter#182996

[brianquinlan]

I wonder if there is some way for the Objective-C trampolines generated by package:ffigen to avoid calling into Dart code if it has already been deleted? Or could we make the VM print a warning message rather than FATAL if the callback is not live (or is that not possible because callbacks can have return values)?

[mraleph]

I wonder if there is some way for the Objective-C trampolines generated by package:ffigen to avoid calling into Dart code if it has already been deleted?

The general answer to this is no. The only way to implement that reliably is to leak them.

[brianquinlan]

I was able to reproduce the same issue using CupertinoClient:

import 'dart:async';
import 'dart:io';
import 'dart:isolate';
import 'package:cupertino_http/cupertino_http.dart';

void main() async {
  final server = await HttpServer.bind('localhost', 0);
  server.listen((request) async {
    await Future.delayed(const Duration(milliseconds: 500));
    request.response.write('Hello');
    await request.response.close();
  });

  print('Server listening on ${server.port}');
  final uri = Uri.parse('http://localhost:${server.port}');

  for (int i = 0; i < 100; ++i) {
    print('Iteration $i');
    await Isolate.run(() async {
      final client = CupertinoClient.defaultSessionConfiguration();
      client.get(uri).ignore();
      client.close();
      // Isolate finishes and shuts down here, while task is in flight.
    });
    await Future.delayed(const Duration(milliseconds: 50));
  }

  print('Waiting for native crashes...');
  await Future.delayed(const Duration(seconds: 5));
  await server.close();
}

Running this results in the same stack trace as above. But fixing this is harder than I thought: even after calling [NSURLSession invalidateAndCancel], [NSOperationQueue cancelAllOperations] and [NSOperationQueue waitUntilAllOperationsAreFinished], the callback can still be invoked (maybe it is already inflight and waiting for the Dart isolate to be available for dispatch?).

I was able to make the above code work by maintaining a global list of running tasks, having each task remove itself when its onComplete handler is run, and then, when close is called, it waits until the list of running tasks is empty. The problem is that I had to change close to return Future, which I can't do because close is defined as part of the Client interface and it returns void.

Even with the above, the crash can still occur if:

1. flutter reload is invoked
2. the developer doesn't call close

[liamappelbe]

Might be able to fix this on the FFIgen side: dart-lang/native#3265. Main unknown is whether I can use Dart_SendPortGetId to detect if the target isolate is shut down.

[brianquinlan]

@liamappelbe had the clever suggestion of doing a fire-and-forgot of the cleanup code in the Client close method.

I thought that scheduled tasks were supposed to keep an isolate alive:

void main() async {
  Isolate.run(() async {
    print('here');
    Future.delayed(const Duration(seconds: 10), () {
      print('there');
    });
    print('everywhere');
  });
}

But that code prints 'here' and 'everywhere' and does not wait for the delayed closure to execute.