CGImageCopyImageSource error in Console

I'm dynamically creating a UIImage from NSData using [UIImage imageWithData:data]. The call succeeds and returns a valid UIImage but every time I make the call

 CGImageCopyImageSource:4692: *** CGImageGetImageSource: cannot get CGImageSourceRef from CGImageRef (CGImageSourceRef was already released)

is printed in the Console - not the Xcode console but the Console app streaming from the device. I haven't determined this is actually a problem but I have customer reports of my app crashing after a long period of time where this particular code path is being called frequently.

If I put a symbolic breakpoint at ERROR_CGImageCopyImageSource_WAS_CALLED_WITH_INVALID_CGIMAGE is is hit.

I'm not sure what I could be doing to cause this error since I'm passing valid data in and getting what looks like valid output.

Replies

Can you replicate this in a small test project?

Share and Enjoy

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

Here is a simple project that reproduces the issue on my machine - https://github.com/jhndnnqsc/iOSImageTest

Xcode Version 14.3 (14E222b) Running iPhone 14 Pro iOS 16.4 simulator Prints default 10:25:56.723025-0600 ImageTest CGImageCopyImageSource:4692: *** CGImageGetImageSource: cannot get CGImageSourceRef from CGImageRef (CGImageSourceRef was already released)

to Console

Honestly, I think this is log noise. I saw the same log output when I ran your app, but I also saw instances of it from Springboard (the process that runs the Home Screen). Now, you code and Springboard could have the same bug, but that seems unlikely.

Share and Enjoy

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

Thanks for the response. i guess I have 2 concerns. The first is that I am getting customer reports of stability that seems to be related to the frequency of that particular code path. When it runs about 5 times a second the app lasts for about 1 day. Decreasing the frequency increases the length of time the app runs. Of course it could be caused by something else in the same code path but that brings up the second issue - the frequency of the call along with the error print out makes the Console log difficult to deal with.

I guess I have 2 questions - is there a way to accomplish the same thing ( updating the contents of a UIImageView ) that doesn’t trigger the message and is it worthwhile to submit a bug? I didn’t think what I was doing was that unique but searching pretty much everywhere didn’t bring up any hits related to that message.

The first is that I am getting customer reports of stability that seems to be related to the frequency of that particular code path.

Given that, I think a stress test is in order. If you set things up to call this code path continuously, how quickly can you get the app to crash?

Oh, one other thing to do here is to add a stress test mode to your test project. If that also triggers the instability, you gain a bunch of benefits:

  • You’ve isolated the issue from the rest of the code in your app, which is strong evidence that this log message is actually relevant.

  • It gives you a project to use when filing a bug.

  • It lets you easily test workarounds.

OTOH, if your test project can’t reproduce the problem, that’s evidence that the issue is tied to your something else in your main app.

the frequency of the call along with the error print out makes the Console log difficult to deal with.

That’s what Console’s filtering is for (-: For hints and tips about this, see Your Friend the System Log.

is there a way to accomplish the same thing ( updating the contents of a UIImageView) that doesn’t trigger the message

UIKit isn’t really my thing, but there are many ways to update the content of an image view. Will any of them help with this issue? It’s hard to answer that because we don’t know the underlying cause of your instability. However, if you can create a stress test that crashes your app promptly, you can then start running experiments.

and is it worthwhile to submit a bug?

Yes, even if this is just log noise.

Share and Enjoy

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