CFNetwork crash in CFURLRequestSetMainDocumentURL

I have received two strange crash reports from an iPad11,7 running iPadOS 15.1 and an iPad11,2 running iPadOS 15.2.

On both occasions, the crashed thread calls CFURLRequestSetMainDocumentURL, which in turn calls _dispatch_source_set_runloop_timer_4CF in libdispatch, after which the application crashes with SIGSEGV and SEGV_MAPERR.

The crashed thread's call stack is displayed below. Full crash logs are attached as well. What could this be?

Exception Type:  SIGSEGV
Exception Codes: SEGV_MAPERR at 0x21d
Crashed Thread:  20

Thread 20 Crashed:
0   libdispatch.dylib                    0x00000001829e1784 _dispatch_source_set_runloop_timer_4CF + 36
1   CFNetwork                            0x00000001834fc824 CFURLRequestSetMainDocumentURL + 2240
2   CFNetwork                            0x00000001836b89a8 _CFNetworkErrorGetLocalizedDescription + 693652
3   CFNetwork                            0x00000001834fdb1c CFURLRequestSetMainDocumentURL + 7096
4   CFNetwork                            0x00000001834f3c34 CFURLRequestSetURL + 9668
5   libdispatch.dylib                    0x00000001829ca914 _dispatch_call_block_and_release + 28
6   libdispatch.dylib                    0x00000001829cc660 _dispatch_client_callout + 16
7   libdispatch.dylib                    0x00000001829d3de4 _dispatch_lane_serial_drain + 668
8   libdispatch.dylib                    0x00000001829d498c _dispatch_lane_invoke + 440
9   libdispatch.dylib                    0x00000001829d5c74 _dispatch_workloop_invoke + 1792
10  libdispatch.dylib                    0x00000001829df1a8 _dispatch_workloop_worker_thread + 652
11  libsystem_pthread.dylib              0x00000001f1eea0f4 _pthread_wqthread + 284
12  libsystem_pthread.dylib              0x00000001f1ee9e94 start_wqthread + 4

Replies

I have received two strange crash reports …

Can you repost these crash reports but this time do the redaction as described in Posting a Crash Report? Your current redaction approach is causing difficulties at my end.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • Many thanks for your swift reply. I have attached updated crash logs to a separate post in this topic. Please let me know if there is anything else I can do.

  • Looking at crash logs from our other application that shares a big chunk of the codebase of this one, I see more SIGSEGV crashes caused by _dispatch_source_set_runloop_timer_4CF. For example, in the callstack of another SIGSEGV crash I see _CFURLStorageSessionCopyCache, followed by 3x _CFNetworkSetATSContext, after which a crash occurs in _dispatch_source_set_runloop_timer_4CF. Without knowing the implementation of that function, could it be that some GCD resources have been exhausted, resulting in the segmentation violation?

Add a Comment

Attached to this post are crash logs with better redaction / alignment.

This is probably worthy of a separate topic, but I do briefly want to mention that the iPadOS 15.2 crash log failed to symbolicate automatically, and is still not fully symbolicated. I had to manually download iOS 15.2 arm64 and arm64e symbols and run symbolication with the symbolicatecrash command line utility. Xcode 13.2 freezes when I try to symbolicate the crash log through the Devices and Simulators window, and apparently Xcode 13.2 did not include the 15.2 symbols. Perhaps this is a result of downloading Xcode 13.2 manually from the Apple Developer downloads website, which was required due to the App Store Xcode issue described here.

Attached to this post are crash logs with better redaction / alignment.

Thanks.

My best guess is this is a bug at our end. The crash was triggered by a memory access exception. The crashing thread looks like this:

Thread 20 Crashed:
0 … libdispatch.dylib … dispatch_source_set_timer + 36 …
1 … CFNetwork         … URLConnectionLoader::loadWithWhatToDo(NSURLRequest*, _CFCachedURLResponse const*, long, URLConnectionLoader::WhatToDo) + 1128 …
…
5 … libdispatch.dylib … _dispatch_call_block_and_release + 32 …

Frame 1 is CFNetwork code being called by Dispatch. I took a look at this code and it’s scheduling a timeout timer. Frame 0 shows Dispatch crashing while it tries to work with this timer. This strongly suggests that the timer that CFNetwork passed in is bogus, and so it’s some sort of object lifetime issue within CFNetwork.

Now, it’s always possible that there’s a bug in your app that’s triggering this. For example, you might have a memory management issue that just happens to trigger this problem. However, that seems unlikely. We’ve seen crashes very similar to this being reported in a wide variety of different apps.

Still, if you’re not already doing this routinely, I recommend that you run your app’s test suite with the standard memory debugging tools to see if that flushes out anything actionable.

Normally at this point I’d point you to a bug that Apple is using to track this. However, the bug situation here is kinda muddied, so I’m going to recommend that you file your own bug about this.

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"

  • Thank you for the analysis. Is there any news regarding this issue? We still seem to experience it on the latest iOS release (15.4.1). Are there any known workarounds? We are considering reimplementing our networking stack using SwiftNIO, but this will take some time

Add a Comment

Is there any news regarding this issue?

What was your bug number?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"