You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I originally found this problem in one of my apps, which was creating millions of image representations. The memory leak on CGImage caused the memory footprint to grow until the process got killed by the kernel.
Apart from a fix to the problem, any recommendations on a memory leak free workaround for the conversion of a CGImage to an in memory Data png representation are welcome.
The text was updated successfully, but these errors were encountered:
I hate to say it, but that's not a workaround; it's a necessary part of working with frameworks implemented in Objective-C. Autorelease pools are a way to delay the destruction of an object, usually for returning values that a caller isn't expecting to have to release themselves. By default, there's a fresh autorelease pool every time an event is handled, but if you've got a loop that's doing a lot of work you may need to add your own like this.
Environment
Apple Swift version 4.2.1 (swiftlang-1000.11.42 clang-1000.11.45.1)
Target: x86_64-apple-darwin18.2.0
Additional Detail from JIRA
md5: fa24e326d689d53529a7d02d27619a19
Issue Description:
Reference counting seems not to be working correctly on CGImage when an png representation is created.
The following minimal test case illustrates the problem:
The problematic call seems to be
I originally found this problem in one of my apps, which was creating millions of image representations. The memory leak on
CGImage
caused the memory footprint to grow until the process got killed by the kernel.Apart from a fix to the problem, any recommendations on a memory leak free workaround for the conversion of a
CGImage
to an in memoryData
png representation are welcome.The text was updated successfully, but these errors were encountered: