I'm adding this here in case someone ends up on this thread through a search and could possibly be investigating similar crashes.
Through to the use of the "Record reference counts" in the Allocations tool, filtering by type ("CGColorSpace") and some logging/breakpoints courtesy of associated objects, I think I have a better picture of what’s going on in Sequoia.
Is there really a regression in CGColorSpaceCreateWithICCData on macOS 15 Sequoia?
To the best of my knowledge, yes, there still appears to be a regression in Sequoia, but it isn't in CGColorSpaceCreateWithICCData. One of the APIs our software uses seems to have gained an extra CFRelease() as compared to previous versions of macOS.
Because our software uses almost every graphics API present in macOS, it’s been very hard to pinpoint who might be responsible for it (some call stacks are in private APIs that aren't easily understood). The list made by the Allocations tool of each CFRetain/CFRelease called on every color space instance is great, but so long in my case as to be impractical. I hope others might have an easier environment to debug this issue in.
If there is nothing wrong with CGColorSpaceCreateWithICCData, what’s really going on?
It appears to be just one CFRelease too many, but there is a reason it was discovered through CGColorSpaceCreateWithICCData. Most times, software ends up using one of the system-provided color spaces created by name (e.g. kCGColorSpaceSRGB). These are singletons, with an infinite retain count. So calling an extra CFRelease on one of these singletons will never produce a crash. Our software, in some circumstances, allocates its own CGColorSpaceRef from ICC data. Whether CoreGraphics maintains a cache or not of these instances, they are regular (non-singleton) instances. So if some API somewhere is responsible for an extra CFRelease, the last unlucky caller to call CFRelease will cause a crash. In your own code, you would notice the reference count for an instance created via CGColorSpaceCreateWithICCData go up and down as it gets passed around, but eventually and unpredictably, when the last use of that color space is complete, you’re likely to see a crash with a stack trace that includes CF_IS_OBJC.
There aren't too many ways to create color spaces that aren't singletons. I suspect color spaces created as derivatives of singletons might also be affected. If you stumble on this page and your code uses stuff like CGColorSpaceCreateLinearized, CGColorSpaceCreateCopyWithStandardRange or similar, then perhaps you have confirmation that derived color spaces are indeed affected by this problem, even when derived from singletons.
Is a workaround possible?
The only brute force solution that seems available is to make sure you maintain your own singletons of every color space created from ICC data or through APIs that derive a new color space from an existing instance. Assuming you’re working with a finite set of ICC profiles, or need a limited set of color spaces derived from others, this global list shouldn't grow too large or grow indefinitely.
Core Foundation has no function that says CFMakeUncollectable() or CFSetRetainCount(+infinity) so not only do you need to maintain a reference to these color spaces in a global pool, you also need to periodically keep its retain count high. Assuming there is really a regression in macOS and not my code, some graphics API somewhere is calling an extra CFRelease any time you use it, so make sure your retain count is always high enough to never allow it to reach zero (e.g. periodically make sure it’s at least 1000).
I'm still hoping the problem is actually in my own code (I'm at the third review already) but just in case this is a real regression in macOS, hope the above helps others.
