Leaks in every filter when used via Cocoapods.(Workaround/Fix)

[atishay]

Use OS_OBJECT_USE_OBJC instead of __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_6_0 for ARC check for GCD or drop iOS 5 altogether.

TL; DR
Coming of a 5 hour investigation. It is a weird combination of Cocoapods, GPUImage and ARC that causes this leak.

• GPUImage defines that it supports iOS 5.0 with ARC in its podspec.
• iOS 5.0 does not have ARC for GCD(GrandCentral Dispatch).
• GPUImage takes care of this by having __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_6_0 checks. It does not use OS_OBJECT_USE_OBJC check which is the correct way to see if ARC for GCD is supported.
• Although the target project that cocapods has is iOS7.1, but as GPUImage specifies the minimum as 5.0, cocoapods prepares GPUImage compile options based on 5.0. That causes all GCD objects to leak.

As a workaround, I have created a local podspec with ios minimum specified as iOS 7. This fixes the bug for me. I can create a pull request with the entire set of find replace throughout the code, but it seems like a waste of time as just changing a number in the podspec fixes this issue. (The shouldn't be a huge number of developers needing GPUImage against iOS5 SDK)

[atishay]

#1435 is also about the same issue.

[demonnico]

👍
Good job, I spend a little time to check it up what you said, and what I got is that you're right.
The compile flag-DOS_OBJECT_USE_OBJC=0 in compile sources created automatically by cocoapods is just the key point. As you said above, a local podspec is the easiest way to fix leaks.

[demonnico]

@atishay811
I'd created a PR here

[MartinHerman]

hey @demon1105 does it mean, that if I installed the latest release (0.1.6) with CocoaPods I won't be having this issue anymore? I still think that the GPUImageFilter leaks for me - 6 filtered images cause 40 MB of memory, which just won't go away for some reason...

[BradLarson]

@MartinHerman - That's something completely different. This leak was never substantial. What you're seeing is the expansion of the framebuffer cache, which will expand the cache as needed. That may cause the allocation of additional memory at times, but the cache will purge itself on a memory warning.

If the cache is not purging itself, or is triggering memory-related crashes, that's something to be concerned with, but is unrelated to the minor memory leak described here.

[MartinHerman]

@BradLarson thanks for the prompt reply!
Oh, you are (almost certainly) right. I did notice that if I repeated the process a few times (on different pictures), memory usage wouldn't go past 50 MB on the iPhone 5. However, is there a way to purge the cache manually? Because my project uses background location services and I suspect the huge memory usage to be the reason of my app crashing sometimes...

[BradLarson]

@MartinHerman You can manually trigger a purge using

[[GPUImageContext sharedFramebufferCache] purgeAllUnassignedFramebuffers]

but this will only purge any framebuffers not actively tied to a UIImage in memory, or a filter being processed. If the above does nothing, then you're hanging on to images longer than you should, and might need to look to make sure you don't have UIImages staying behind in memory when they shouldn't. You may need to rearchitect your filtering process.

[MartinHerman]

@BradLarson yes! That does it for me.
GPUImage is one of the most extensive frameworks for iOS out there - great work!

[demonnico]

@MartinHerman
Sorry to reply you so late, nice to know that you got it.
👍