Crash: com.apple.CFNetwork.Connection (libcorecrypto.dylib)

Question

Created Jun ’23

Replies 5

Boosts 0

Views 1.4k

Participants 2

Experiencing alot of crash in libcorecrypto.dylib. Also stack trace doesn't provide much information. So can we pls get a help on this?

Stack trace:

Crashed: com.apple.CFNetwork.Connection EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000051da5f80

Crashed: com.apple.CFNetwork.Connection 0 libcorecrypto.dylib 0x5bb30 ccmode_gcm_update_pad + 48 1 libcorecrypto.dylib 0x673c ccmode_gcm_set_iv + 356 2 libcorecrypto.dylib 0x5baac ccgcm_set_iv + 104 3 libboringssl.dylib 0x35ba4 aead_aes_gcm_seal_scatter + 220 4 libboringssl.dylib 0x29ca4 EVP_AEAD_CTX_seal_scatter + 296 5 libboringssl.dylib 0x84e94 bssl::SSLAEADContext::SealScatter(unsigned char*, unsigned char*, unsigned char*, unsigned char, unsigned short, unsigned char const*, bssl::Span<unsigned char const>, unsigned char const*, unsigned long, unsigned char const*, unsigned long) + 932 6 libboringssl.dylib 0x23404 bssl::do_seal_record(ssl_st*, unsigned char*, unsigned char*, unsigned char*, unsigned char, unsigned char const*, unsigned long) + 404 7 libboringssl.dylib 0x22f08 bssl::tls_seal_record(ssl_st*, unsigned char*, unsigned long*, unsigned long, unsigned char, unsigned char const*, unsigned long) + 312 8 libboringssl.dylib 0x4903c bssl::do_tls_write(ssl_st*, int, unsigned char const*, unsigned int) + 472 9 libboringssl.dylib 0x49500 bssl::tls_dispatch_alert(ssl_st*) + 116 10 libboringssl.dylib 0x5459c SSL_shutdown + 204 11 libboringssl.dylib 0x6730 boringssl_session_disconnect + 76 12 libboringssl.dylib 0xf8d8 nw_protocol_boringssl_disconnect + 96 13 Network 0x901b04 -[NWConcrete_nw_endpoint_flow cancelWithHandler:forced:] + 1304 14 Network 0x3fcc80 nw_endpoint_handler_cancel + 1068 15 Network 0x35969c __nw_connection_cancel_inner_block_invoke + 1208 16 Network 0x358f6c nw_connection_cancel_inner + 316 17 Network 0x358bb8 nw_connection_cancel + 116 18 CFNetwork 0x37080 CFURLRequestSetShouldStartSynchronously + 7304 19 CFNetwork 0xd5678 _CFURLCachePersistMemoryToDiskNow + 7212 20 CFNetwork 0xd5430 _CFURLCachePersistMemoryToDiskNow + 6628 21 libdispatch.dylib 0x2320 _dispatch_call_block_and_release + 32 22 libdispatch.dylib 0x3eac _dispatch_client_callout + 20 23 libdispatch.dylib 0xb534 _dispatch_lane_serial_drain + 668 24 libdispatch.dylib 0xc0d8 _dispatch_lane_invoke + 436 25 libdispatch.dylib 0xd394 _dispatch_workloop_invoke + 1764 26 libdispatch.dylib 0x16cdc _dispatch_workloop_worker_thread + 648 27 libsystem_pthread.dylib 0xddc _pthread_wqthread + 288 28 libsystem_pthread.dylib 0xb7c start_wqthread + 8

com.apple.main-thread 0 libsystem_kernel.dylib 0xc84 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x13b54 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x13e2c mach_msg_overwrite + 540 3 libsystem_kernel.dylib 0x11c8 mach_msg + 24 4 CoreFoundation 0x79114 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x7a340 __CFRunLoopRun + 1208 6 CoreFoundation 0x7f4dc CFRunLoopRunSpecific + 612 7 GraphicsServices 0x135c GSEventRunModal + 164 8 UIKitCore 0x39d37c -[UIApplication _run] + 888 9 UIKitCore 0x39cfe0 UIApplicationMain + 340 10 <app name> 0x18b10 main + 17 (main.swift:17) 11 ??? 0x1dbca8dec (Missing)

Boost

Answer 1

DTS Engineer OP

Apple

Jun ’23

Experiencing alot of crash in libcorecrypto.dylib.

Please post a full Apple 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

pateldhruvil96 OP

Jun ’23

Hi, please check the full stack trace fetched from firebase crashlytics

CrashStackTrace.txt

0

Answer 3

DTS Engineer OP

Apple

Jun ’23

fetched from firebase crashlytics

Sadly, I can’t do anything useful with a third-party crash report [1]. I recommend that you remove your third-party crash reporter and wait for a similar crash to come through the Apple crash reporting system.

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

[1] In many cases, like this one, they don’t contain the info required to analyse hard problems. However, there are also constraints that make them fundamentally untrustworthy. For the details, see Implementing Your Own Crash Reporter.

0

Answer 4

pateldhruvil96 OP

Jun ’23

Sure. Have attached the full apple crash report, please check.

fyi: Was unable to attach it via All file option as it was throwing something went wrong error hence uploaded the .txt crash report file

https://we.tl/t-NOMLcRLIZc

0

Answer 5

DTS Engineer OP

Apple

Jun ’23

Thanks for the crash report.

The presence of the Last Exception Backtrace section indicates that the app crashed due to an unhandled language exception. However, the backtrace is interesting:

Last Exception Backtrace:
0 CoreFoundation      … __exceptionPreprocess + 164 (NSException.m:202)
1 libobjc.A.dylib     … objc_exception_throw + 60 (objc-exception.mm:356)
2 CFNetwork           … -[__NSURLSessionLocal taskForClassInfo:] + 1300 (LocalSession.mm:0)
3 NewRelic            … NRMAOverride__dataTaskWithRequest_completionHandler + 288 (NRMAURLSessionOverride.m:245)
4 FirebasePerformance … __InstrumentDataTaskWithRequestCompletionHandler_block_invoke + 232 (FPRNSURLSessionInstrument.m:312)
5 testApp             … closure #1 in SwAPIRequest<>.send() + 428 (SwAPIRequest.swift:59)

AFAICT your code in frame 5 has called your third-party middleware in frame 4. From there things get weird. I suspect that frame 3 is another third-party library that’s swizzled its way into the code path. That suspicion is based solely on the Override in based on the name of NRMAOverride__dataTaskWithRequest_completionHandler. Regardless, you need to discuss this with your third-party vendors.

Oh, one last thing: That crash report dosen’t mention libcorecrypto at all. Are you sure you posted the right one?

Oh, and I lied about that being the last thing (-: The crash report you posted also indicates your using a third-party crash reporter (see frame 5 on thread 8). Third-party crash reporters are not to be trusted, as I explain in Implementing Your Own Crash Reporter. I recommend that you disable that before trying to debug this further.

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

0