Crash in URLSession task teardown after the app goes to the background (EXC_BAD_ACCESS _taskGroup) #26321

Sentry: JETPACK-IOS-1H42

Sentry snapshot (as of Oct 30, 2026)

EXC_BAD_ACCESS: _taskGroup (KERN_INVALID_ADDRESS), culprit objc_retain. Fatal.

• First seen: Jul 21, 2025. Total: 1,323 events, 306 users.
• Last 30 days: 27.3: 95 events / 92 users · 27.2: 21 / 20 · 27.1: 2 · 26.8: 1.
• Not a 27.3 regression. 27.3 has about 4.2× as many users reporting any error as 27.2 (2,388 vs 573), and 92 vs 20 users is about 4.6×, so it's flat per user. It's one of the highest-volume crashes, though.
• Devices: iPhone only. All of the top 9 device models are iPhones (iPhone 12 to 18 families). OS: iOS 26.5 to 27.2, mostly 26.6.x.

Stack

The crash is on a GCD worker thread, not the main thread, with no first-party frames. Reading from the crash upward:
objc_retain ← -[NSURLSessionTask session] ← -[__NSCFLocalSessionTask localSession] ← -[__NSCFLocalSessionTask dealloc] ← URLProtocol::~URLProtocol (CFNetwork) ← … nw_quic_connection / nw_proxy_deallocate_options releases ← nw_connection_report_state_with_handler_on_nw_queue ← -[NWConcrete_nw_path_evaluator dealloc] ← nw_association_schedule_deactivation.

So _taskGroup here is an internal CFNetwork / Network.framework symbol, not a Swift concurrency TaskGroup. A URLSessionTask is being deallocated as its HTTP/3 (QUIC) connection is torn down, and it reaches back to an NSURLSession that has already been freed.

Breadcrumbs (4 recent 27.3 events)

• 3 of 4: the app comes to the foreground, the usual sync burst runs (dashboard, notifications, stats), and then the app goes to the background. The last request is a Tracks POST /rest/v1.1/tracks/record sent at the moment of backgrounding. The crash follows 3–6 seconds after backgrounding (in_foreground: false on the event).
• 1 of 4: the app is in the foreground in the legacy editor (EditPostViewController › GutenbergViewController), about 40 seconds after a Tracks POST.

Candidate code (hypotheses, not confirmed)

1. A URLSession invalidated or released while a task is in flight. WordPressComRestApi.deinit, WordPressOrgXMLRPCApi, WordPressOrgRestApi and TracksMini all call finishTasksAndInvalidate() in deinit, and invalidateAndCancelTasks() is called from Blog and WPAccount.prepareForDeletion. There are about 55 call sites that build a fresh WordPressComRestApi (defaultV2Api(...) etc.), so throwaway clients whose session dies with in-flight requests are common.
2. The Tracks flush at background time (AutomatticTracks TracksService) racing app suspension. It's the last network activity in 3 of 4 events.
3. An Apple CFNetwork/QUIC bug in task teardown on iOS 26. If so, the possible workaround is to keep sessions alive longer, or to disable HTTP/3 (assumesHTTP3Capable / per-request .http3 off) to test the theory.

Repro to try

The simulator is unlikely to reproduce this: it's a race with real network teardown and app suspension, and it's iPhone-only in the field. Use a real iPhone on iOS 26.6 with Zombie Objects and Address Sanitizer on.

1. Open My Site › Home (Activity Log card visible), then Stats. Background the app within 1–2 seconds of each sync starting. Repeat 20 or more times.
2. Do the same with the network switching between Wi-Fi and cellular, which triggers nw_path_evaluator changes.
3. With a breakpoint on -[__NSCFLocalSessionTask dealloc], check which session owner (the WordPressComRestApi instance or Tracks) has already been deallocated.

Representative events

a176cbbc020e466ca52334c3c3b6dd7a · ad97a69731f7440396da6b13d184fb2d · c55ae3f868154198b0d7779e37bd3d8c · 3fe3d324e5244341984ba573ce20143a (editor, foreground) · a37a74a7cd674193adf5543d20aa424f

Generated by Claude Code