New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
atishay opened this Issue Sep 3, 2014 · 9 comments

Comments

Projects
None yet
4 participants
@atishay

atishay commented Sep 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@atishay

atishay Sep 4, 2014

#1435 is also about the same issue.

atishay commented Sep 4, 2014

#1435 is also about the same issue.

@atishay atishay changed the title from Leaks in every filter when used via Cocoapods. to Leaks in every filter when used via Cocoapods.(Workaround/Fix) Sep 4, 2014

@demonnico

This comment has been minimized.

Show comment
Hide comment
@demonnico

demonnico Sep 4, 2014

Contributor

👍
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.

Contributor

demonnico commented Sep 4, 2014

👍
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

This comment has been minimized.

Show comment
Hide comment
@demonnico

demonnico Sep 4, 2014

Contributor

@atishay811
I'd created a PR here

Contributor

demonnico commented Sep 4, 2014

@atishay811
I'd created a PR here

@BradLarson BradLarson closed this Sep 16, 2014

@MartinHerman

This comment has been minimized.

Show comment
Hide comment
@MartinHerman

MartinHerman Sep 30, 2014

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...

MartinHerman commented Sep 30, 2014

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

This comment has been minimized.

Show comment
Hide comment
@BradLarson

BradLarson Sep 30, 2014

Owner

@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.

Owner

BradLarson commented Sep 30, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@MartinHerman

MartinHerman Sep 30, 2014

@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...

MartinHerman commented Sep 30, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@BradLarson

BradLarson Sep 30, 2014

Owner

@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.

Owner

BradLarson commented Sep 30, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@MartinHerman

MartinHerman Sep 30, 2014

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

MartinHerman commented Sep 30, 2014

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

@demonnico

This comment has been minimized.

Show comment
Hide comment
@demonnico

demonnico Oct 7, 2014

Contributor

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

Contributor

demonnico commented Oct 7, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment