app crashed _CFRelease.cold.1

Crashes in CFRelease are almost always due to memory management problems. I recommend that you apply the standard memory debugging tools to see if they offer any insight into the issue.

If not, please capture a crash report and post it here. See Posting a Crash Report for advice on how to do that.

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

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

this method … is a iOS private api, so I think it should be a problem in the iOS.

That’s certainly possible, but it’s just as likely that your code has a memory management problem that’s affecting some unrelated code. Again, the standard memory debugging tools should help you isolate this issue.

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

@gemdama @DTS Engineer same case,Is there a solution?

Is there a solution?

If this is a memory management issue then there are a wide variety of potential causes, meaning there’s no guarantee that the root cause of gemdama’s problem is same root cause of whatever problem you’re seeing. I recommend taht you work through the steps in my initial response.

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

Hi, eskimo, I met the same crash. It may RPScreenRecorder inner crash. From crash log, the reason of crash is caused by CFRelease(NULL).

Triggered by Thread:  39
Application Specific Information:

*** CFRelease() called with NULL ***


Thread 39 Crashed:
0   CoreFoundation                	       0x185cde1f4 CFRelease.cold.1 + 16
1   CoreFoundation                	       0x185b36dc4 CFRelease + 132
2   ReplayKit                     	       0x23b16f770 __56-[RPScreenRecorder captureHandlerWithSample:timingData:]_block_invoke + 148
3   libdispatch.dylib             	       0x1bd502adc _dispatch_call_block_and_release + 32
4   libdispatch.dylib             	       0x1bd51c7ec _dispatch_client_callout + 16
5   libdispatch.dylib             	       0x1bd50b468 _dispatch_lane_serial_drain + 740
6   libdispatch.dylib             	       0x1bd50bf44 _dispatch_lane_invoke + 388
7   libdispatch.dylib             	       0x1bd5163ec _dispatch_root_queue_drain_deferred_wlh + 292
8   libdispatch.dylib             	       0x1bd515ce4 _dispatch_workloop_worker_thread + 692
9   libsystem_pthread.dylib       	       0x1e097b3b8 _pthread_wqthread + 292
10  libsystem_pthread.dylib       	       0x1e097a8c0 start_wqthread + 8

See assembly below, the result of RPSampleBufferUtilities_CreateSampleBufferFromIOSurface is NULL, then CFRelease() called with NULL cause crash.

From crash log, the reason of crash is caused by CFRelease(NULL).

Right, but that doesn’t tell you much. A memory management crash indicates that some code has done something wrong with the heap. The challenge is that the heap is one giant piece of shared mutable state. So there’s no guarantee that the code that crashed is in any way related to the code that has the bug. It certainly could be, but it could also be an innocent victim of some other code’s problem.

As you’ve noted, the value being released is the return result from RPSampleBufferUtilities_CreateSampleBufferFromIOSurface. So is that bug that:

• -captureHandlerWithSample:timingData: should be checking for NULL?
• Or that RPSampleBufferUtilities_CreateSampleBufferFromIOSurface shouldn’t be returning NULL?

It’s hard to say without understanding that the design contract between those two subsystems. And if the design is such that RPSampleBufferUtilities_CreateSampleBufferFromIOSurface should never fail, to learn more you have to dig into the code to figure out why it failed.

Are you able to reproduce this? Or are you debugging it based on crash reports coming in from the field?

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

I can reproduce the crash, but it doesn't always happen, the scene of crash has a bit complicated. Here a .ips file from user(for attach it change .ips to .txt), I don't know if the .ips can provide some useful information. Last reply I forget attach it.

Here a .ips file from user

Thanks!

Sometimes an JSON (.ips) crash report allows me to find existing bug reports associated with the crash. Sadly, that didn’t pan out in this case.

I can reproduce the crash, but it doesn't always happen

OK, that means you’re doing better (well, worse :-) than anyone else in this thread. And I think that warrants you filing a bug about this. Make sure to:

1. Reproduce the crash.
2. Immediately trigger a sysdiagnose log.
3. Attach that to your crash report.

Note For more about sysdiagnose logs, see our Bug Reporting > Profiles and Logs page.

Once you’re done, please post your bug number here so that I can add my own (internal) comments to it.

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

Hi, eskimo, I have posted a bug with sysdiagnose logs and crash log. The bug number is FB22904017.

By the way, it's my first time to know how to collect sysdiagnose logs 🤦🏻‍♀️.

By the way, I learn a lot from yours articles like An Apple Library Primer, Implementing Your Own Crash Reporter and so on. Does has any way to get all your articles like above?

The bug number is FB22904017.

Thanks!

Does has any way to get all your articles like above?

No, but more because an accident of history than any good reason. We’ve recently been talking about this over in Cannot access profile page of individual DTS engineers.

Having said that, most of these posts are linked to from the various Resources posts that are pinned to the top of various topics, subtopic, and tags. For example, Notarisation Resources has links to a bunch of my posts, and it’s pinned to the Code Signing > Notarization subtopic and the Notarization tag.

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