Starting with iOS 18.3, we are getting infrequent crash reports somehow related to web sockets. Are there any new caveats we should be aware of or is it just a CFNetwork bug?
Incident Identifier: 0D4343CE-3089-4514-841D-80CEC353B6B8
Distributor ID: com.apple.AppStore
Hardware Model: iPhone16,2
AppStoreTools: 16C7015
AppVariant: 1:iPhone16,2:18
Code Type: ARM-64 (Native)
Role: Non UI
Parent Process: launchd [1]
Date/Time: 2025-03-18 15:42:14.1732 -0400
Launch Time: 2025-03-15 20:38:20.7015 -0400
OS Version: iPhone OS 18.3.1 (22D72)
Release Type: User
Baseband Version: 2.40.05
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes: 0x0000000000000001, 0x0000000000000000
VM Region Info: 0 is not in any region. Bytes before following region: 4373233664
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 104aa4000-104aa8000 [ 16K] r-x/r-x SM=COW /var/containers/Bundle/Application/EDB47FCF-9E2C-4BE3-A771-F6F84BFCAF31/<redacted>
Termination Reason: SIGNAL 11 Segmentation fault: 11
Terminating Process: exc handler [4454]
Thread 10 Crashed:
0 CFNetwork 0x0000000193c46aac -[__NSURLSessionWebSocketTask _onqueue_receiveMessageWithCompletionHandler:] + 256 (LocalWebSocketTask.mm:486)
1 CFNetwork 0x0000000193c438b0 -[__NSURLSessionWebSocketTask _onqueue_ioTick] + 636 (LocalWebSocketTask.mm:355)
2 CFNetwork 0x0000000193c46918 __67-[__NSURLSessionWebSocketTask receiveMessageWithCompletionHandler:]_block_invoke + 356 (LocalWebSocketTask.mm:97)
3 libdispatch.dylib 0x000000019a2e9248 _dispatch_call_block_and_release + 32 (init.c:1549)
4 libdispatch.dylib 0x000000019a2eafa8 _dispatch_client_callout + 20 (object.m:576)
5 libdispatch.dylib 0x000000019a2f25cc _dispatch_lane_serial_drain + 768 (queue.c:3934)
6 libdispatch.dylib 0x000000019a2f3158 _dispatch_lane_invoke + 432 (queue.c:4025)
7 libdispatch.dylib 0x000000019a2fe38c _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193)
8 libdispatch.dylib 0x000000019a2fdbd8 _dispatch_workloop_worker_thread + 540 (queue.c:6787)
9 libsystem_pthread.dylib 0x000000021d2e4680 _pthread_wqthread + 288 (pthread.c:2696)
10 libsystem_pthread.dylib 0x000000021d2e2474 start_wqthread + 8 (:-1)
Thread 10 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x00000000000003f0 x3: 0x0000000000000001
x4: 0x0000000000000010 x5: 0x00000000b04d793d x6: 0x00000000000013c0 x7: 0x0000000000000000
x8: 0x0000000000000378 x9: 0x0000000000000001 x10: 0x00000001fabc6b40 x11: 0x000000000000000f
x12: 0x0000000000ddf700 x13: 0x000000012a1bc1c0 x14: 0x00000001fabc9798 x15: 0x00000001fabc9798
x16: 0x000000018faa1c4c x17: 0x000000019a2ea664 x18: 0x0000000000000000 x19: 0x0000000303a83420
x20: 0x0000000000000000 x21: 0x000000012b42d900 x22: 0x00000001fc8000a8 x23: 0x00000001fc8000a8
x24: 0x00000003036913c0 x25: 0x00000003036913c0 x26: 0x0000000000000001 x27: 0x0000000303afc870
x28: 0x0000000000000001 fp: 0x000000016b95a1f0 lr: 0x0000000193c46a04
sp: 0x000000016b95a170 pc: 0x0000000193c46aac cpsr: 0x40001000
esr: 0x92000006 (Data Abort) byte read Translation fault
all we have is crash reports from the App Store in Xcode.
Hmmm. This is using the Xcode organiser, right? I thought that had a way to get a JSON crash report, but I don’t have the details. I’m researching that.
The reason why a JSON crash report is so helpful is that I can feed it into internal tools to look for related crashes.
What surprises me a bit is "Role: Non UI" in all but one crash instance though the app does not use any background modes.
Well, as we say in the docs:
This field is generally not helpful when you analyze a crash report.
(-:
Even if you don’t do anything to opt in to background execution, it’s still possible to run in the background. The most obvious case of this is that the system gives you a short amount of background execution time after you move to the background and it’s delivered the did-enter-background notification.
If all these crashes have the Non UI role then it’s possible that this is being triggered by the foreground-to-background or background-to-foreground transition. If you don’t do anything special here your app will be suspended shortly after moving to the background. That will likely tear network connections, and that causes the networking stack to run uncommon code paths, which could trigger a failure like this.
We do use NSURLSessionWebSocketTask, though.
Indeed. I’m not a big fan of URL session’s WebSocket support, hence the recommendation in TN3151 Choosing the right networking API [1]. If you were starting from scratch I’d definitely recommend you use Network framework. However, you already have this code written, and I’m reluctant to advise you to rewrite it all without concrete evidence that it’ll help. It’s a tricky one, because it could actually help with this, but it could also just being shuffling deckchairs.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] For more background, see this post.