Crash in CFNetwork

Question

oswaldo OP

Created May ’23

Replies 3

Boosts 0

Views 1.3k

Participants 2

Our App is starting to crash (SIGABRT) with the following Assertion failure:

Assertion failed: (CFReadStreamGetStatus(_stream.get()) == kCFStreamStatusNotOpen), function _onqueue_setupStream_block_invoke, file HTTPRequestBody.cpp, line 878.

Some context and details:

It´s only happening for iOS 16.x versions, although our app is supported also in iOS15.
crash started to happen a few days after the release date
app state is foreground
it´s happening in almost every kind of device
deployment target is iOS 15.0

Nothing in any is the other threads indicates this could be related to our code, that´s the stack trace of the affected threads:

Thread 7 Queue 1417: com.apple.CFNetwork.Connection(serial):

0    libdispatch.dylib                        0x1d8469548     _dispatch_lane_serial_drain + 688
1    libdispatch.dylib                        0x1d846a0d8     _dispatch_lane_invoke + 435
2    libdispatch.dylib                        0x1d846b394     _dispatch_workloop_invoke + 1763
3    libdispatch.dylib                        0x1d8474cdc     _dispatch_workloop_worker_thread + 647
4    libsystem_pthread.dylib                  0x23092fddc     _pthread_wqthread + 287
5    libsystem_pthread.dylib                  0x23092fb7c     start_wqthread + 7

Thread 8 Unknown:

0    libsystem_kernel.dylib                   0x20fcb1c84     mach_msg2_trap + 8
1    libsystem_kernel.dylib                   0x20fcc4e2c     mach_msg_overwrite + 539
2    libsystem_kernel.dylib                   0x20fcb21c8     mach_msg + 23
3    Instabug                                 0x104152c40     exception_server_thread + 187
4    libsystem_pthread.dylib                  0x2309306b8     _pthread_start + 147
5    libsystem_pthread.dylib                  0x23092fb88     thread_start + 7

Thread 9 com.apple.NSURLConnectionLoader [Crashed]:

0    libsystem_kernel.dylib                   0x20fcb8558     __pthread_kill + 8
1    libsystem_c.dylib                        0x1d84c2178     abort + 179
2    libsystem_c.dylib                        0x1d851a0a4     __assert_rtn + 271
3    CFNetwork                                0x1d21a4948     _CFNetworkHTTPConnectionCacheGetLimit + 158579
4    libdispatch.dylib                        0x1d8461eac     _dispatch_client_callout + 19
5    libdispatch.dylib                        0x1d846591c     _dispatch_block_invoke_direct + 263
6    CFNetwork                                0x1d22017cc     _CFURLStorageSessionDisableCache + 56783
7    CoreFoundation                           0x1d0fafe88     CFArrayApplyFunction + 71
8    CFNetwork                                0x1d22016bc     _CFURLStorageSessionDisableCache + 56511
9    CFNetwork                                0x1d2203c64     _CFURLStorageSessionDisableCache + 66151
10   CoreFoundation                           0x1d106c208     __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 27
11   CoreFoundation                           0x1d1078864     __CFRunLoopDoSource0 + 175
12   CoreFoundation                           0x1d0ffd6c8     __CFRunLoopDoSources0 + 243
13   CoreFoundation                           0x1d10131c4     __CFRunLoopRun + 827
14   CoreFoundation                           0x1d10184dc     CFRunLoopRunSpecific + 611
15   CFNetwork                                0x1d22027e0     _CFURLStorageSessionDisableCache + 60899
16   Foundation                               0x1cb2c3634     __NSThread__start__ + 715
17   libsystem_pthread.dylib                  0x2309306b8     _pthread_start + 147
18   libsystem_pthread.dylib                  0x23092fb88     thread_start + 7

Answered by oswaldo in 753843022

Thank you, I´ve included one of the crashes we receive in the Xcode Organizer:

2023-05-23_16-42-07.6249_+0200-cda5fd36efc8d2b68cefdf75451f843003a06fda.crash

Boost

Answer 1

DTS Engineer OP

Apple

May ’23

Our App is starting to crash (SIGABRT) with the following Assertion failure:

Please post a full crash report, using the instructions in Posting a Crash Report.

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

0

Answer 2

oswaldo OP

May ’23

Accepted Answer

Thank you, I´ve included one of the crashes we receive in the Xcode Organizer:

2023-05-23_16-42-07.6249_+0200-cda5fd36efc8d2b68cefdf75451f843003a06fda.crash

0

Answer 3

DTS Engineer OP

Apple

May ’23

There’s a big difference between the backtrace in that crash report and the backtrace snippets you posted earlier. My best guess is that this is bogus symbolication in those snippets. For example, the huge offset in frame 3 of the crashing thread suggests that _CFNetworkHTTPConnectionCacheGetLimit is not actually involved here.

The weird thing, however, is the thread name. There’s no sign of com.apple.NSURLConnectionLoader in your real crash report, and I can’t readily explain that.

Thread 3 of the crash report shows that you’re using a third-party crash reporter. I don’t trust third-party crash reports [1] so it’s hard to be sure that this crash report is actually indicative of the real problem.

Still, at first blush this looks like a straightforward trap within CFNetwork’s HTTP support. Your app is trying to run an HTTP request whose body is a stream, for example, by setting the HTTPBodyStream property on NSMutableURLRequest. CFNetwork is checking that the stream is not open, and traps if it is.

I’m not sure why this behaviour changed — that trap has been around for a while now — but the path forward is clear: Look for any requests that use a body stream and check that you supply a closed stream.

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

[1] And for good reason. See Implementing Your Own Crash Reporter for the full backstory here.

0