iOS15.x Crash in CFNetwork : _CFNetworkErrorGetLocalizedDescription

you can see full crash report below

That doesn’t look like an Apple crash report. Do you have one of those handy?

FYI, I don’t look at third-party crash reports because it’s not possible to create a reliable third-party crash reporter, and double so on iOS. For all the gory details, see Implementing Your Own Crash Reporter.

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

i got apple Apple crash report , you can check this, thank you !

Thanks.

My best guess is that this crash is caused by a bug in CFNetwork itself but it’s hard to be sure. Normally bugs like this produce a lot of ‘signal’ — that is, from the Apple side we see a lot of crash reports — but the signal here is quite weak. Having said that, it does seem to affect more than just your app, so it’s either a problem on our side or a problem in some third-party library that’s used by a bunch of folks.

Your crash report is not fully symbolicated. For example, the main thread looks like this:

Thread 0 name:
Thread 0:
0   happy           0x0000000100c5a180 0x1008d4000 + 3694976
1   happy           0x00000001042a6238 0x1008d4000 + 60629560
2   happy           0x00000001042a69a4 0x1008d4000 + 60631460
3   happy           0x0000000104288028 0x1008d4000 + 60506152
4   happy           0x000000010428c284 0x1008d4000 + 60523140
5   happy           0x00000001042b23f0 0x1008d4000 + 60679152
6   happy           0x00000001042b4754 0x1008d4000 + 60688212
7   WebKit          0x00000001be75b1c8 ScriptMessageHandlerDelegate::didPo…
8   WebKit          0x00000001beaa8da4 WebKit::WebUserContentControllerPro…
13  WebKit          0x00000001be7d19f8 IPC::Connection::dispatchIncomingMe…

where the Apple frames (13 through 7) have symbols but the frames related to your code (frames 6 through 0) do not. I recommend that you work at symbolicating your frames as well. It’s possible that this context might suggest what’s happening within your app that’s triggering the crash.

For information on symbolication, see Adding Identifiable Symbol Names to a Crash Report.

If you are able to better symbolicate this, post an updated crash report and I’ll take another look.

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

Thanks for your reply, i post a fully symbolicated crash report.

Thanks for the fully symbolicated log.

I just noticed your crash reports are missing some UUID values in the Binary Images section. For example, the CFNetwork entry is missing the UUID:

0x18d4be000 - 0x18d97efff CFNetwork arm64e   /System/Library/Frameworks/CFNetwork.framework/CFNetwork

but the UUID is present for JavaScriptCore:

0x197ed4000 - 0x199249fff JavaScriptCore arm64e  <6592b928ee2c3bc2b4e94cdc77022fe0> /System/Library/Frameworks/JavaScriptCore.framework/JavaScriptCore

Are those UUIDs missing in your original crash report?

Your new crash report highlighted one oddity that, while I don’t think this is the cause of your crash, needs investigation.

Consider your main thread:

Thread 0 name:
Thread 0:
0   libsystem_kernel.dylib … semaphore_wait_trap + 8
1   libdispatch.dylib      … _dispatch_sema4_wait + 28 (lock.c:139)
2   libdispatch.dylib      … _dispatch_semaphore_wait_slow + 132 (semaphore.c:132)
3   happy                  … -[UMNetworkWork postDataToServer:withFile:] + 600
4   happy                  … -[UMNetworkWork postDataWithFile:] + 1100
5   happy                  … -[UMNetworkWork main] + 640

This looks like it’s running a network operation on the main thread. If so, that’s not a good idea because, if something goes wrong with the network, you’ll end up being killed by the watchdog.

As to your crash, it seems that CFNetwork is talking to an HTTP/2 server and so it’s pulling various properties out of your request and using them to build strings that are appropriate for its underlying HTTP/2 code. Hence the http2CreateCStringFromCFString(…) call in frame 1. That calls is being passed a NULL CFString reference, and hence the crash in CFStringGetLength in frame 0. As to how it got that NULL reference, that’s hard to say. The line number in the backtrace of the called, HTTP2Stream.cpp:540, doesn’t quite line up with my view of the world, which means I’m not 100% confident that I’m interpreting this right.

And that brings me back to the UUID issue I mentioned above. Those UUIDs are critical to investigating problems like this, so I kinda need to get that sorted out.

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