Core Graphics is not just in iOS. It's also defined in OS X. (This is a perpetual source of confusion in the developer forums. iOS and OS X are very nearly identical, with APIs that have a vast number of features in common. A developer will ask a question with one OS in mind, and get answers relating to the other. The trouble is that "nearly identical" does not mean "identical", and the differences can be subtle but significant. Each OS has its own complete set of documentation, and when you search for something you'll find results from both sets intermingled. You have to filter the results based on which OS is pertinent at the time.)
The documentation for CGContextClosePath in OS X can be found here
. You will notice that it's word-for-word identical to the documentation for CGContextClosePath in iOS, except the final line says "Available in OS X v10.0 and later".
Since all the error messages reflect OS X apps (Safari, Preview, Finder, etc.), it's probably safe to say the messages relate to the OS X version, not the iOS version. All of which is a minor point, that I go into only so that readers will not be left wondering how iOS code might have found its way into OS X apps.
What is probably happening has to do with the distinction between bitmap graphics and vector graphics. If you want to embed an image in a document, you (by which I mean "a program that you write") can either render it yourself and include the resulting pixels (possibly compressed), or you can capture the drawing commands in a form that lets them be carried out on the viewer's computer. The former method (bitmap graphics) tends to produce bigger files with lower resolution. The latter method (vector graphics) tends to produce smaller documents that nevertheless utilize all of the available resolution. Except for images that are either very small or are basically photographs, vector graphics are to be preferred.
But if you're capturing drawing commands, one of the commands being captured might be "CGContextClosePath". That command may have been thrown into the mix because the programmer generating the image wasn't sure whether it would be needed (there might be multiple paths through the code, some of which started a path and some of which didn't), and took to heart the comment in the documentation that said:
If the current path is empty or the current subpath is already closed, this function does nothing.
and figured it would be harmless to close the path whether it needed to be closed or not.
But apparently the documentation is not quite accurate. It should probably have said " ... this function does nothing except log a message
." Which the image will do any time it's drawn in any application.
The fix would be to replace the image with a more carefully constructed equivalent image. Trouble is, whoever constructed the image in the first place probably never noticed the log messages, and probably will not feel motivated to re-construct and re-deploy the image even if the messages are pointed out. Or get Apple to stop logging the message, or at least lower its log priority so it won't appear unless you've set the log priority to include debugging messages. But Apple probably isn't highly motivated to stop displaying a message that everyone is going to ignore anyway.