Core Image and Memory Leak, Swift 3.0

Core Image and memory leak, swift 3.0

It's not a memory leak; it's that you are in fact using too much memory. And it's not the use of CIFilter that's causing the problem; it's the fact that you are trying to keep all of these huge UIImage objects in memory in a single array:

var result = [UIImage]()
// ...
result.append(newImage)

Don't do that.

Memory leak when filtering with Core image

You set variables to nil before you call release, so the release has no effect. But you should not release most of the stuff anyway. You only need to release objects that you created (I hope the following list is complete):

• Objective-C objects that were returned by methods starting with alloc, init, copy, new
• Foundation objects returned by Objective-C methods starting with create, or by functions containing Create or Copy.

Delete these lines and it should be fine:

beginImage = nil;
context = nil;
filter = nil;
outputImage = nil;
cgimg = nil;
[beginImage release];
[context release];
[filter release];
[outputImage release];

You need to keep the line CGImageRelease(cgimg); because the method used to get cgimg contains create – you create it, you release it.

Swift 3 CGImage Memory issue

I found the solution to my problem.

I didn't know that UIKit is not thread safe. It appears that executing that code in a thread different from the main, does not allow the system to free the memory as it should.

On the main thread, the memory is correctly released and managed.

Memory Leak on scaling image in iOS using SWIFT

You have to autorelease the call to scaledImage.

autoreleasepool {
  previewImage = scaledImage(originalImage: originalImage, scaledToSize: desiredSize)
}

How to investigate into memory leaks in ios?

Starting from your second question.

With instruments aside, your code is segueing a UIViewController and dismiss it if simple as that, let us not think about retain cycles just yet.

Strong vs Weak vs Unowned –

1- Usually, when a property is being created, the reference is strong unless they are declared weak or unowned.

2- With the property labelled as weak, it will not increment the reference count

3- An unowned reference falls in between, they are neither strong nor or type optional
Compiler will assume that object is not deallocated as the reference itself remain allocated.

What is retain cycle:

Unless there is some other reference to the parent or child, they both become orphaned. But the retain cycle between the parent and child prevent either from
being released and they become wasted memory.

A child should never retain a parent. If anything, use a weak
reference in the child to maintain a reference to the parent.

Now lets take a look on what you have, you are using UINavigationController & segue, well the UINavigationController is a LIFO stack, also according to apple

A navigation controller is a container view controller that manages one or more child view controllers in a navigation interface. In this type of interface, only one child view controller is visible at a time.

So checking your UIViewController deinit function i think you would have no problem telling that the reference deallocated.

Now lets try to look to something else in the UIAlertAction you have this [unowned self].

When to use unowned self or weak self

The only time where you really want to use [unowned self] or [weak
self] is when you would create a strong reference cycle. A strong
reference cycle is when there is a loop of ownership where objects end
up owning each other (maybe through a third party) and therefore they
will never be deallocated because they are both ensuring that each
other stick around.

In the specific case of a closure, you just need to realize that any
variable that is referenced inside of it, gets "owned" by the closure.
As long as the closure is around, those objects are guaranteed to be
around. The only way to stop that ownership, is to do the [unowned
self] or [weak self]. So if a class owns a closure, and that closure
captures a strong reference to that class, then you have a strong
reference cycle between the closure and the class. This also includes
if the class owns something that owns the closure.

And as you said switching both [unowned self] and [self] did nothing.

Now the first question,

Well instruments leak checks are simple its a simply compare the significant increases in memory in the period of time, and compares it all to each others based on whats going on, this is not a 100% description but close, so whenever that green tick pops up it means you passed the test. doesn't mean 100% you are safe yet, you can visually see the allocation in the bottom section of instrument, observe the values changes (increasing/ decreasing) .. if something in increasing without ever decreasing, i think you found you problem.

Looking into your case i don't think you would find one

---

Related Topics