Help with crash in framework code - freeing completion blocks?

Hello. I have a mysterious crash that I can't reproduce. The stack traces never have any of my code in them. Here is what I know about the crashes:
  1. It doesn't seem to be at all device-specific, but newer devices are far more commonly seen than older devices.

  2. It only happens on iOS 14 and up

  3. It might possibly be related to airplay (I work on a video player app), because every crash report also has either a thread labeled com.apple.coremedia.displaymirroringobserver or a thread labeled AVAudioSession Notify Thread

Here is the stack trace:

Code Block language
Crashed: com.apple.main-thread 
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000020
0 libobjc.A.dylib 0x1bfa07de0 objc_release + 16
1 libsystem_blocks.dylib 0x1f315d784 _Block_release + 188
2 UIKitCore 0x1ae37bf14 -[_UIAfterCACommitBlock run] + 76
3 UIKitCore 0x1adee1984 _runAfterCACommitDeferredBlocks + 296
4 UIKitCore 0x1aded0eb4 _cleanUpAfterCAFlushAndRunDeferredBlocks + 200
5 UIKitCore 0x1adf02484 _afterCACommitHandler + 76
6 CoreFoundation 0x1ab5e687c __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
7 CoreFoundation 0x1ab5e0f50 __CFRunLoopDoObservers + 604
8 CoreFoundation 0x1ab5e1498 __CFRunLoopRun + 960
9 CoreFoundation 0x1ab5e0ba0 CFRunLoopRunSpecific + 572
10 GraphicsServices 0x1c2346598 GSEventRunModal + 160
11 UIKitCore 0x1aded22f4 -[UIApplication _run] + 1052
12 UIKitCore 0x1aded7874 UIApplicationMain + 164
13 SpectrumTV 0x1029874d0 main + 29 (SettingsAboutAnalyticsReporter.swift:29)
14 libdyld.dylib 0x1ab2bf568 start + 4

This seems to indicate that we are doing something wrong with a Core Animation completion block. When the OS tries to free the completion blocks, it crashes. But, that still leaves me with a huge search surface area, so I was hoping that by posting here, someone (perhaps someone with knowledge of the code in question) could point me at specifically what causes the above framework code to run.

The other option is that someone is corrupting the heap, which is too horrifying to contemplate. 😱
Are you able to share the entire crash report using the paperclip attachment feature?

Without seeing the entire crash report, one interesting observation is the address 0x20. This isn't the address range used by objects — those addresses start above 2^32 — so low-byte range addresses like this are sometimes indicators of non-objects, like something with the value 0x20 could be an integer or a floating-point value. I sometimes see crashes where a value like that got passed around and eventually set as a pointer to an object with the address of that value, rather than used as the value itself. If that's correct, then this is crashing in objc_release because the system is attempting to release what it thinks is a pointer to an object, but it's not an object.

When you see any Objective-C runtime function as the top frame in a stack trace, like objc_release here, it's likely a zombie object is the source of the error. However, in this case, this can't be a zombie, because of the address of the invalid pointer as described above is just way outside of the normal pointer range. I mention this as a clue of what not to look for to help rule some things out.

Have you tried Address Sanitizer? See also Quinn's Standard Memory Debugging tips.
I thought you might ask for the whole crash log. Unfortunately we are using Crashlytics for crash reports and I have not yet found a way to access the raw crash report text. I just have a stack trace and some OS/device data that I assume was parsed from source log data.

The other threads in the stack trace are invariably all idle, with nothing of note going on.

I can try running the app with the address sanitizer enabled, but without knowing what the user was doing at the time of crash, it's a bit of a stab in the dark. Thank you for the suggestion nonetheless, I will give it a shot.

I managed to track down a full raw crashlog for this crash. I have attached it below.

Address sanitizer found no issues in our testing. I was able to track down and fix a memory leak, but that did not address the crash.

To help aid reproducing this, see Thread 16, where the system us using MediaToolbox — focus your attempts to reproduce this on code paths involving AV media content. I did some investigation, and this is likely resulting from an issue in the system frameworks. Your best course of action here is to file a bug report using Feedback Assistant with the crash report, plus any other info you're able to gather from getting a reproducible scenario for this. Once you've done so, post the FB number here.

We never were able to find a way to reproduce this bug in-house. However, it seems that Apple has managed, either accidentally or on purpose, to fix this crash with iOS 15. We have not seen a single instance of this crash on the new OS, and on iOS 14 it was our top crasher.

If you had something to do with that, @edford, thank you.

Help with crash in framework code - freeing completion blocks?
 
 
Q