Problem Description
I've encountered a crash that only appears on iOS 17.2 and later versions (specifically iOS 17.2, iOS 17.2.1, and iOS 17.3). The crash started occurring after we switched our CDN to HTTP/3. Reverting the CDN back to a previous version eliminated the crash.
The crash is of type EXC_BAD_ACCESS (SIGSEGV) with a KERN_INVALID_ADDRESS error. It was triggered in Thread 8, and the stack trace points to functions within the Network framework.
I am unsure which part of my code is causing this issue when using HTTP/3.
Any insights into what might be causing this crash or how to troubleshoot it would be greatly appreciated.
Thank you.
Steps to Reproduce
It cannot be reproduced at present, but there are many crash logs in the crash report.
Crash Report
Triggered by Thread: 8
Kernel Triage:
VM - (arg = ) mach_vm_allocate_kernel failed within call to vm_map_enter
VM - (arg = ) mach_vm_allocate_kernel failed within call to vm_map_enter
VM - (arg = ) mach_vm_allocate_kernel failed within call to vm_map_enter
Thread 8 name:
Thread 8 Crashed:
0 Network <memory_address> nw_protocol_error + 68 (protocol.cpp:577)
1 Network <memory_address> nw_channel_disconnect_flow(nw_channel*, nw_channel_input_flow*) + 172 (channel.cpp:2168)
2 Network <memory_address> invocation function for block in nw_channel_handle_defunct(nw_channel*) + 40 (channel.cpp:2928)
3 Network <memory_address> nw_hash_table_apply + 2696 (hash_table.cpp:454)
4 Network <memory_address> nw_channel_handle_defunct(nw_channel*) + 644 (channel.cpp:2926)
5 Network <memory_address> nw_channel_check_defunct(nw_channel*) + 92 (channel.cpp:2996)
6 Network <memory_address> nw_channel_remove_input_handler(nw_protocol*, nw_protocol*, bool) + 3332 (channel.cpp:661)
7 Network <memory_address> nw_protocol_ipv4_remove_input_handler(nw_protocol*, nw_protocol*, bool) + 148 (protocol_ip.cpp:639)
8 Network <memory_address> nw_protocol_udp_remove_input_handler(nw_protocol*, nw_protocol*, bool) + 156 (protocol_udp.cpp:271)
9 Network <memory_address> nw_protocol_implementation_teardown + 1028 (protocol_implementation.m:936)
10 Network <memory_address> nw_protocol_implementation_remove_input_handler + 2988 (protocol_implementation.m:0)
11 CFNetwork <memory_address> ConnectionProtocolRemoveInputHandler(nw_protocol*, nw_protocol*, bool) + 264 (ConnectionProtocol.cpp:102)
12 Network <memory_address> nw_endpoint_flow_failed_with_error(NWConcrete_nw_endpoint_handler*, bool, NSObject<OS_nw_error>*) + 536 (endpoint_flow.cpp:3449)
13 libdispatch.dylib <memory_address> _dispatch_call_block_and_release + 32 (init.c:1530)
14 libdispatch.dylib <memory_address> _dispatch_client_callout + 20 (object.m:561)
15 libdispatch.dylib <memory_address> _dispatch_workloop_invoke + 2152 (queue.c:4485)
16 libdispatch.dylib <memory_address> _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:6913)
17 libdispatch.dylib <memory_address> _dispatch_workloop_worker_thread + 404 (queue.c:6507)
18 libsystem_pthread.dylib <memory_address> _pthread_wqthread + 288 (pthread.c:2629)
19 libsystem_pthread.dylib <memory_address> start_wqthread + 8 (:-1)
If you’re using the high-level NSURLSession API then it’s hard to imagine how you might trigger this crash deep within Network framework. Even if you’re CDN is doing something completely wrong, Network framework shouldn’t crash. I recommend that you file a bug about this.
Make sure to include whatever info you have. Ideally this would be a sysdiagnose log taken shortly after seing the crash. If you have any users that see this problem regularly, you could ask them to collect that for you. However, you should still file a bug even if you can only include crash reports.
Please post your bug number, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"