Strange iOS Crash Only on iOS 13.X, unable to find the cause of crash

Thread 1 name:
Thread 1:
0 libsystem_kernel.dylib … mach_msg_trap + 8
1 libsystem_kernel.dylib … mach_msg + 72 (mach_msg.c:103)
2 libsystem_kernel.dylib … task_threads + 92 (taskUser.c:590)
3 MYAPP                  … ARS_suspendEnvironment + 128 (ARSCrash_MachException.m:60)
4 MYAPP                  … __51+[ARS_SeeaxyvkQaaAVDId installMachExceptionHandler]_block_invoke + 280 (ARSCrash_MachException.m:200)
5 libdispatch.dylib      … _dispatch_call_block_and_release + 24 (init.c:1408)
…

It looks like you’re using a third-party crash reporter and it’s disrupted the crash state seen by the Apple crash reporter. My recommendation is that you remove the third-party crash reporter and see if that improves the quality of the Apple crash reports, thereby allowing you to debug this problem.

ps I generally recommend against using a third-party crash report. My Implementing Your Own Crash Reporter explains why.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I will check the codes of third-party crash reporter.

Thank you.

I will check the codes of third-party crash reporter.

Cool.

For the sake of other folks reading this thread, I want to clarify this comment:

It looks [your] third-party crash reporter [has] disrupted the crash state seen by the Apple crash reporter.

What brought me to that conclusion? Well, consider this snippet from your crash report:

Exception Type:  EXC_CRASH (SIGSEGV)
…
Triggered by Thread:  0

This indicates that your app crashed because of a memory access exception on thread 0. However, the backtrace for thread 0 is this:

Thread 0 name:
Thread 0 Crashed:
0 libsystem_kernel.dylib … mach_msg_trap + 8
1 libsystem_kernel.dylib … mach_msg + 72 (mach_msg.c:103)
2 CoreFoundation         … __CFRunLoopServiceMachPort + 216 (CFRunLoop.c:2575)
3 CoreFoundation         … __CFRunLoopRun + 1444 (CFRunLoop.c:2931)
4 CoreFoundation         … CFRunLoopRunSpecific + 464 (CFRunLoop.c:3192)
5 GraphicsServices       … GSEventRunModal + 104 (GSEvent.c:2246)
6 UIKitCore              … UIApplicationMain + 1936 (UIApplication.m:4773)
7 MYAPP                  … main + 152 (main.m:16)
8 libdyld.dylib          … start + 4

This means that thread 0 was blocked inside UIKit’s main thread run loop waiting for an event. How can it trigger a memory access exception while blocked? That’s possible, but very unlikely.

Looking through the rest of your crash report I see this:

Thread 21 name:
Thread 21:
0   libobjc.A.dylib         … objc_release + 16 (objc-object.h:551)
1   CFNetwork               … URLResponse::~URLResponse() + 52 (AutoTypes.h:39)
2   libobjc.A.dylib         … object_cxxDestructFromClass(objc_object*, objc_class*) + 112 (objc-class.mm:452)
3   libobjc.A.dylib         … objc_destructInstance + 88 (objc-class.mm:467)
4   libobjc.A.dylib         … _objc_rootDealloc + 48 (objc-runtime-new.mm:7606)
5   CFNetwork               … -[NSURLResponseInternal dealloc] + 40 (NSURLResponse.mm:63)
6   CFNetwork               … -[NSURLResponse(NSURLResponsePrivate) dealloc] + 28 (NSURLResponse.mm:351)
7   CFNetwork               … -[NSHTTPURLResponse dealloc] + 64 (NSURLResponse.mm:622)
…

That’s a much more likely cause for this crash. However, we can’t be sure because something has caused the crash reporter to point to the wrong thread. The presence of a third-party crash reporter in the backtrace of thread 1 is by far the most likely explanation of that disruption.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Cool! Your guess is correct.

A few days ago I closed the third-party crash reporter via a remote switch.

Now I see a significant increase in such crashes in Xcode Organizer.

Thread 22 name:
Thread 22 Crashed:
0   libobjc.A.dylib                0x00000001bd850140 objc_release + 16 (objc-object.h:174)
1   CFNetwork                      0x00000001c0e0a63c URLResponse::~URLResponse() + 52 (AutoTypes.h:39)
2   libobjc.A.dylib                0x00000001bd8350e8 object_cxxDestructFromClass(objc_object*, objc_class*) + 112 (objc-class.mm:452)
3   libobjc.A.dylib                0x00000001bd847d7c objc_destructInstance + 88 (objc-class.mm:467)
4   libobjc.A.dylib                0x00000001bd84edb0 _objc_rootDealloc + 48 (objc-runtime-new.mm:7606)
5   CFNetwork                      0x00000001c0d585f0 -[NSURLResponseInternal dealloc] + 40 (NSURLResponse.mm:63)
6   CFNetwork                      0x00000001c0d57e48 -[NSURLResponse(NSURLResponsePrivate) dealloc] + 28 (NSURLResponse.mm:351)
7   CFNetwork                      0x00000001c0d579e0 -[NSHTTPURLResponse dealloc] + 64 (NSURLResponse.mm:622)
8   CFNetwork                      0x00000001c0e81230 HTTPProtocol::validateCachedResponseForLoad(_CFCachedURLResponse const*) + 1744 (HTTPProtocol.cpp:0)
9   CFNetwork                      0x00000001c0e6b650 HTTPProtocol::_protocolInterface_isCachedResponseValidNonBlocking(_CFCachedURLResponse const*) + 12 (HTTPProtocol.cpp:1868)
10  CFNetwork                      0x00000001c0ec1574 invocation function for block in URLConnectionLoader::continueWithCacheLookupResult(NSURLRequest*... + 52 (URLConnectionLoader.cpp:1640)
11  CFNetwork                      0x00000001c0ebe7c0 invocation function for block in URLConnectionLoader::withExistingProtocolAsync(void (URLProtocol... + 32 (URLConnectionLoader.cpp:1124)
12  CFNetwork                      0x00000001c0f6ac88 invocation function for block in QCoreSchedulingSet::performAsync(void () block_pointer) const + 52 (CoreSchedulingSet.mm:190)
13  libdispatch.dylib              0x00000001bd7da610 _dispatch_call_block_and_release + 24 (init.c:1408)
14  libdispatch.dylib              0x00000001bd7db184 _dispatch_client_callout + 16 (object.m:495)
15  libdispatch.dylib              0x00000001bd7b8710 _dispatch_lane_serial_drain$VARIANT$armv81 + 564 (inline_internal.h:2484)
16  libdispatch.dylib              0x00000001bd7b915c _dispatch_lane_invoke$VARIANT$armv81 + 452 (queue.c:3863)
17  libdispatch.dylib              0x00000001bd7ba27c _dispatch_workloop_invoke$VARIANT$armv81 + 1736 (inline_internal.h:2525)
18  libdispatch.dylib              0x00000001bd7c243c _dispatch_workloop_worker_thread + 576 (queue.c:6445)
19  libsystem_pthread.dylib        0x00000001bd82ab88 _pthread_wqthread + 276 (pthread.c:2351)
20  libsystem_pthread.dylib        0x00000001bd82d760 start_wqthread + 8

https://gist.github.com/***7758258/e3d224a7ecff9a17119cfd2e37c89ff4

Next I will check the network transport layer.

Thank you.

With regards your new crash report, that’s a lot cleaner. Unfortunately it doesn’t help us that much. Your process is crashing deep within CFNetwork. It’s possible that this is a bug in your app, but my experience is that crashes like this are most commonly caused by race condition bugs within CFNetwork itself.

I ran your crash report through some internal tools here and they pointed to various older CFNetwork bugs. Looking at those bugs, I don’t see any indication that this specific problem was ever fixed. The issue with crashes like these is that can be very difficult to uncover the root cause.

My initial advice is that you run your app through its test suite with the standard memory debugging tools enabled (separately, don’t enable zombies and ASan at the same time!). This may cause the bug to show up repeatably, in which case we can debug things from there.

If that doesn’t turn up anything interesting then your next best option is to file a bug report with the information you have. Unfortunately, without a reproducible case, or even a sysdiagnose log taken shortly after the crash, it’s going to be hard for the CFNetwork team to make any progress on this.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Can we set setenv("CFNETWORK_DIAGNOSTICS", "3", 1) in appstore app? Do we need to add additional message/information to user for enabling network logs?

Can we set setenv("CFNETWORK_DIAGNOSTICS", "3", 1) in appstore app?

Absolutely not! [1] If you’re trying to debug a networking problem that only shows up in the field, have the user sent you a sysdiagnose log. If that doesn’t have the info you need, they can install a configuration profile to enable more debugging. For more details on this, and to download the various network debugging configuration profiles, go to our Bug Reporting > Profiles and Logs page.

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

[1] Well, I’m not sure whether you can, but you definitely shouldn’t.