Activity

1. orestesgaolin

   assigned

   brianquinlan

   on Mar 17, 2026
2. orestesgaolin

   added

   type-bugIncorrect behavior (everything from a crash to more subtle misbehavior)Incorrect behavior (everything from a crash to more subtle misbehavior)

   package:cupertino_httpIssues related to package:cupertino_httpIssues related to package:cupertino_http

   on Mar 17, 2026
3. orestesgaolin

   changed the title [-]cupertino_http crashes on iOS[/-] [+]cupertino_http crashes on iOS on wrapListenerBlock[/+] on Mar 17, 2026
4. orestesgaolin

   changed the title [-]cupertino_http crashes on iOS on wrapListenerBlock[/-] [+]cupertino_http 2.4.0 crashes on iOS on wrapListenerBlock[/+] on Mar 17, 2026
5. mraleph commented on Mar 25, 2026

   

   mraleph

   on Mar 25, 2026

   Member

   More actions

   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.

   👍React with 👍1Reacted by Dominik Roszkowski
6. orestesgaolin commented on Mar 25, 2026

   

   orestesgaolin

   on Mar 25, 2026

   Author

   More actions

   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.
7. brianquinlan commented on Mar 25, 2026

   

   brianquinlan

   on Mar 25, 2026

   Last edited by brianquinlan

   Collaborator

   More actions

   @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
8. brianquinlan commented on Mar 25, 2026

   

   brianquinlan

   on Mar 25, 2026

   Collaborator

   More actions

   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)?
9. mraleph commented on Mar 25, 2026

   

   mraleph

   on Mar 25, 2026

   Member

   More actions

   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.
10. brianquinlan commented on Mar 25, 2026

    

    brianquinlan

    on Mar 25, 2026

    Collaborator

    More actions

    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

    👀React with 👀1Reacted by Dominik Roszkowski
11. liamappelbe commented on Mar 26, 2026

    

    liamappelbe

    on Mar 26, 2026

    Contributor

    More actions

    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.
12. brianquinlan commented on Mar 30, 2026

    

    brianquinlan

    on Mar 30, 2026

    Collaborator

    More actions

    @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.

    👀React with 👀1Reacted by Dominik Roszkowski
13. brianquinlan commented on Mar 30, 2026

    

    brianquinlan

    on Mar 30, 2026

    Collaborator

    More actions

    Before dart:ffi supported asynchronous callbacks, package:cupertino_http had its own callback implementation that used SendPorts to communicate between Dart and native code (e.g.

    http/pkgs/cupertino_http/src/CUPHTTPClientDelegate.m

    Line 58 in a41141d

    - (void)URLSession:(NSURLSession *)session

    ).

    I could resurrect that code. Possibly it could also set a timeout for its locks and, if the lock times-out, it could most a message to Dart. If that post fails then it could assume that the receive port is closed and that the isolate is dead.

    👀React with 👀1Reacted by Dominik Roszkowski
14. brianquinlan commented on Mar 30, 2026

    

    brianquinlan

    on Mar 30, 2026

    Collaborator

    More actions

    Ahhh.... one confusing thing is that ObjCProtocolBuilding has a keepIsolateAlive property, which is default true. But that won't keep isolates started with Isolate.run() alive because those isolates are terminated with exit.
15. 10 remaining items

    Load more

16. brianquinlan commented on Apr 27, 2026

    

    brianquinlan

    on Apr 27, 2026

    Last edited by brianquinlan

    Collaborator

    More actions

    I have another thought on how to approach this: package:cupertino_http can keep track of active HTTP requests and throw StateError if there are any. package:cronet_http already does this because the underlying cronet library works like this; shutdown throws if there are active requests.

    I'll also change the documentation to close to be more emphatic that it should be called before isolate exit.

    This won't prevent a crash if the user doesn't close CupertinoClient (and, in fact, you may crash after the excepting is thrown) but it is better than nothing and at least you will understand the "why" of the crash.

    👍React with 👍1Reacted by Liam Appelbe
17. clemortel commented on Apr 28, 2026

    

    clemortel

    on Apr 28, 2026

    More actions

    We're hitting the same crash in production. Adding aggregate data in case it helps narrow it down.

    Setup

    • Flutter iOS app in production, cupertino_http 2.4.0 pulled transitively via native_dio_adapter 1.5.1
    • All Dio traffic on iOS goes through NativeAdapter(), no direct cupertino_http use

    Scale (rolling 7 days)

    • ~244 events / ~106 unique users
    • SIGNAL_REPETITIVE from Crashlytics — ~5 crashes per affected user
    • 3 distinct issue variants under one Crashlytics issue
    • First seen in our app v1.2.491, still present at v1.2.622 — bug has not been triggered by any app change in our codebase across that range, which lines up
      with iOS 26 rollout being the inflection point

    Reproduction context

    • 100% in processState: BACKGROUND (matches OP's "99%+ when not in foreground")
    • iOS 26.0, 26.3, 26.4 all confirmed
    • Devices: iPhone 13 Pro / 14 Pro / 15 Pro (ARM64)
    • Memory at crash: 4.4–7.3 GB resident, 178–222 MB free (high pressure but well below jetsam limits)
    • Last breadcrumb is consistently a screen_view followed shortly by analytics events — the user backgrounds the app while requests are in flight

    Stack signatures we see (three variants of the same root cause)

    Variant A — didReceiveData path:
    abort
    InternalFlutterGpu_Texture_AsImage ← misattributed, real symbol unresolved
    _NativeCupertinoHttp_protocolTrampoline_1tz5yf
    __77-[__NSCFURLSessionDelegateWrapper dataTask:didReceiveData:completionHandler:]_block_invoke_3
    -[NSBlockOperation main]

    Variant B — didReceiveResponse path:
    abort
    InternalFlutterGpu_Texture_AsImage
    ___NativeCupertinoHttp_wrapListenerBlock_xx612k_block_invoke
    _NativeCupertinoHttp_protocolTrampoline_xx612k
    __81-[__NSCFURLSessionDelegateWrapper dataTask:didReceiveResponse:completionHandler:]_block_invoke

    Variant C — same path, deeper mangling into Swift symbol thunks.

    Note on symbolication: the InternalFlutterGpu_Texture_AsImage frame is misattributed (offsets 159 KB – 1.2 MB from the named export) — Crashlytics resolves
    to the nearest exported symbol in the stripped Flutter.framework binary. Per OP, the real crash is DLRT_GetFfiCallbackMetadata. App-side dSYM upload is
    configured correctly via flutterfire upload-crashlytics-symbols; the engine binary just doesn't ship debuggable symbols.

    Workarounds tried

    • None landed yet. Considering switching off native_dio_adapter on iOS (falling back to Dio's default IOHttpClientAdapter) since [cupertino_http] CupertinoClient requests hang and fail to complete #1702 mentioned IOClient as
      a workaround for a similar cupertino_http issue.
18. corepuncher commented on May 31, 2026

    

    corepuncher

    on May 31, 2026

    Last edited by corepuncher

    More actions

    I am seeing what appears to be the same crash in a production using cupertino_http 2.4.0.

    Exception Type: EXC_CRASH (SIGABRT)
    Triggered by Thread: 16
    
    Thread 16 Crashed:
    libsystem_kernel.dylib __pthread_kill
    libsystem_pthread.dylib pthread_kill
    libsystem_c.dylib abort
    Flutter dart::Assert::Fail(char const*, ...) const
    Flutter DLRT_GetFfiCallbackMetadata
    cupertino_http ___NativeCupertinoHttp_wrapListenerBlock_xx612k_block_invoke
    cupertino_http _NativeCupertinoHttp_protocolTrampoline_xx612k
    CFNetwork __NSCFURLSessionDelegateWrapper dataTask:didReceiveResponse:completionHandler:
    Foundation -[NSBlockOperation main]
    

    The app uses CupertinoClient.fromSessionConfiguration(URLSessionConfiguration.defaultSessionConfiguration()) through a shared API client layer.

    Updated Info: In my app, one user reproduced the same crash family while the app was foregrounded, actively panning map/tiled imagery (so hundreds of tile requests). The app uses native_dio_adapter for FlutterMap tile imagery, which depends on cupertino_http, so many concurrent tile requests may be triggering the same wrapListenerBlock/protocolTrampoline path.

    👀React with 👀1Reacted by Dominik Roszkowski
19. timmaffett commented on Jun 4, 2026

    

    timmaffett

    on Jun 4, 2026

    More actions

    Using cupertino_http 3.0.2 it still happens - oddly when running locally on device in release mode it seems to work - but 3 consecutive TestFlight builds (with different workaround attempts to not crash) crashed immediately on device. Then I found this issue...

    Crash: EXC_BAD_ACCESS (null PC) in wrapListenerBlock trampoline on URLSession didReceiveResponse — iOS 26.5 / arm64e, release builds only

    We're hitting this reliably in release/TestFlight builds on iOS 26.5. It is 100% reproducible in release and never reproduces under the debugger (JIT) — consistent with an AOT / arm64e code-pointer issue in the generated Objective-C block trampoline.

    Environment

    cupertino_http	3.0.2
    objective_c	9.4.1
    ffi	2.2.0
    http	1.6.0
    Flutter	3.44.1 (stable)
    OS	iOS 26.5 (23F77)
    Devices	iPhone 16e (iPhone17,5) and iPhone 16 Pro Max (iPhone17,2) — both arm64e
    Build	release (AOT); reproduced across 3 separate builds, identical signature

    Exception

    Exception Type:  EXC_BAD_ACCESS (SIGKILL/SIGBUS)
    Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000000000000000
    Termination Reason: CODESIGNING 2 Invalid Page  (Instruction Abort / Translation fault, esr 0x82000006)
    Registers: pc = 0x0000000000000000   lr = 0x0000000112965a3c (into cupertino_http)
    

    The CPU branches to pc = 0x0 — the listener block's underlying callback pointer is null/invalid when CFNetwork invokes the delegate.

    Faulting thread (symbolicated)

    dSYM UUID 0CEA1CB2-26CE-35CC-AD84-AE661D904629 (matches the crash image).

    0   ???                       0x0000000000000000            <- branch to null PC
    1   cupertino_http            ___NativeCupertinoHttp_wrapListenerBlock_xx612k_block_invoke + 204
    2   cupertino_http            _NativeCupertinoHttp_protocolTrampoline_xx612k + 144
    3   CFNetwork                 __81-[__NSCFURLSessionDelegateWrapper dataTask:didReceiveResponse:completionHandler:]_block_invoke + 168
    4   libdispatch.dylib         _dispatch_call_block_and_release + 32
    5   libdispatch.dylib         _dispatch_client_callout + 16
    6   libdispatch.dylib         _dispatch_lane_serial_drain + 740
    7   libdispatch.dylib         _dispatch_lane_invoke + 448
    8   libdispatch.dylib         _dispatch_root_queue_drain_deferred_wlh + 284
    9   libdispatch.dylib         _dispatch_workloop_worker_thread + 720
    10  libsystem_pthread.dylib   _pthread_wqthread + 292
    11  libsystem_pthread.dylib   start_wqthread + 8
    

    Notes

    • The crash fires on the first delegate callback (didReceiveResponse), on a libdispatch worker thread, for ordinary requests — it is not tied to cancellation or timeouts.
    • The client is a single long-lived CupertinoClient.fromSessionConfiguration (ephemeral config + URLCache), never closed; requests are sent via package:http.
    • Workaround that fully avoids it: switch the iOS HTTP client to IOClient (dart:io), i.e. don't instantiate CupertinoClient. This confirms the fault is in the objective_c trampoline path, not in our usage.

    👍React with 👍2Reacted by corepuncher and Per Lycke
20. PerLycke commented on Jun 9, 2026

    

    PerLycke

    on Jun 9, 2026

    More actions

    Crashed: cupertino_http.NSURLSessionDelegateQueue (QOS: UNSPECIFIED)
    0  libsystem_kernel.dylib         0x7200 __pthread_kill + 8
    1  libsystem_pthread.dylib        0x71ac pthread_kill + 268
    2  libsystem_c.dylib              0x20c8c abort + 180
    3  Flutter                        0x52114c InternalFlutterGpu_Texture_AsImage + 159476
    4  Flutter                        0x5d5118 InternalFlutterGpu_Texture_AsImage + 896704
    5  ???                            0x10c2653c8 (Missing)
    6  cupertino_http                 0x8250 ___NativeCupertinoHttp_wrapListenerBlock_xx612k_block_invoke + 204
    7  cupertino_http                 0x8250 ___NativeCupertinoHttp_wrapListenerBlock_xx612k_block_invoke + 204
    8  cupertino_http                 0x8620 _NativeCupertinoHttp_protocolTrampoline_xx612k + 144
    9  CFNetwork                      0x6f934 CFURLConnectionCreateWithProperties + 11296
    10 Foundation                     0xa72f0 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 24
    11 Foundation                     0x7b4a0 -[NSBlockOperation main] + 104
    12 Foundation                     0x7b430 __NSOPERATION_IS_INVOKING_MAIN__ + 16
    13 Foundation                     0x3c7d8 -[NSOperation start] + 708
    14 Foundation                     0x3c50c __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 16
    15 Foundation                     0x41c20 __NSOQSchedule_f + 172
    16 libdispatch.dylib              0x13114 _dispatch_block_async_invoke2 + 148
    17 libdispatch.dylib              0x3fdc _dispatch_client_callout + 20
    18 libdispatch.dylib              0x746c _dispatch_continuation_pop + 504
    19 libdispatch.dylib              0x6ad4 _dispatch_async_redirect_invoke + 584
    20 libdispatch.dylib              0x15a6c _dispatch_root_queue_drain + 396
    21 libdispatch.dylib              0x16284 _dispatch_worker_thread2 + 164
    22 libsystem_pthread.dylib        0xdbc _pthread_wqthread + 228
    23 libsystem_pthread.dylib        0xb98 start_wqthread + 8
    

    This is what we see in Crashlytics, too often, related to this issue. I'm not invested enough in the code to perfectly understand the cause or contribute to a fix, but I hope others are 🤞
21. brianquinlan commented on Jul 1, 2026

    

    brianquinlan

    on Jul 1, 2026

    Collaborator

    More actions

    • The client is a single long-lived CupertinoClient.fromSessionConfiguration (ephemeral config + URLCache), never closed; requests are sent via package:http.

    So you are not closing the CupertinoClient before exiting the isolate? Could you try closing the CupertinoClient and see if you can reproduce the issue in cupertino_http 3.0.2.
22. stwime commented on Aug 13, 2026

    

    stwime

    on Aug 13, 2026

    Contributor

    More actions

    I think ffigen 21.0.0 fixes this, and regenerating cupertino_http against it turned out to be a one-line change.

    dart-lang/native#3265 closed on 2026-07-22 and shipped in ffigen 21.0.0 ("Fix memory leaks, deadlocks, and crashes that can happen in callbacks, if the target isolate is shut down"), with the runtime half in objective_c 9.5.0. But 3.0.2 pins ffigen: ^20.1.0, and its checked-in native_cupertino_bindings.m still calls the Dart callback directly (grep -c invokeListenerPortBlock returns 0), so bumping objective_c on its own does nothing.

    I cloned the repo, changed only ffigen: ^20.1.0 to ^21.0.0, and ran dart run ffigen --config ffigen.yaml. No config migration was needed, no hand-written source had to change, and dart analyze lib/ is clean. Your Isolate.run repro from above aborts at around iteration 9 on stock 3.0.2 and survives all 100 iterations after the regen. dart test gives 542 passed / 34 skipped both before and after, which is the part I'd most want a second opinion on, since the regen rewrites about 57k lines.

    On closing the client first: that can't help as of 3.0.2. Every iteration of the repro printed Bad state: cannot close with running requests and the process still aborted. close() throws in exactly the situation that crashes.

    Would you consider a release with regenerated bindings? Happy to open a PR.
23. dcharkes commented on Aug 13, 2026

    

    dcharkes

    on Aug 13, 2026

    Contributor

    More actions

    Would you consider a release with regenerated bindings? Happy to open a PR.

    cc @brianquinlan or otherwise @liamappelbe

    👍React with 👍1Reacted by stwime
24. liamappelbe commented on Aug 13, 2026

    

    liamappelbe

    on Aug 13, 2026

    Contributor

    More actions

    @stwime Sounds good. Brian is back from vacation next week. I'm sure he'd appreciate a PR. Would it make sense to turn the repro case into a regression test, or would it take too long to run because it's flaky and has to be repeated?
25. stwime

    added 4 commits that reference this issue on Aug 14, 2026

    [cupertino_http] Regenerate bindings with ffigen 21

    ...

    330844c

    [cupertino_http] Regenerate bindings with ffigen 21

    ...

    82c60bb

    [cupertino_http] Regenerate bindings with ffigen 21

    ...

    45b812e

    [cupertino_http] Regenerate bindings with ffigen 21

    ...

    37a3ff7
26. stwime commented on Aug 14, 2026

    

    stwime

    on Aug 14, 2026

    Contributor

    More actions

    @liamappelbe test looks to be cheap and reliable, so I added one. On my machine, old bindings fail at iteration 9 every time I run it (15/15 runs, ~0.9s in), with regenerated bindings surviving 100. I set it to 20 iterations, which costs about 5s, maybe a little more on the CI.

    PR is at #1975

    👍React with 👍1Reacted by Dominik Roszkowski
27. brianquinlan

    closed this as completedin #1975on Sep 2, 2026