Memory Leak Detected in iOS Instruments profiler - #195
Conversation
During profiling we found a memory leak in our app. The Leak pointed to how the dispatch_source_t was being managed. These changes seemed to cleanly resolve the mort issue and are in line with Apple’s usage documentation.
This will allow me to use my branch as a pod.
I don't want this as part of the pull request originally sent to Philipp. Just need it for my own purposes.
|
+1 ! @jasonbodie can you squash your commits ? |
|
👍 |
During profiling we found a memory leak in our app. The Leak pointed to how the dispatch_source_t was being managed. These changes seemed to cleanly resolve the mort issue and are in line with Apple’s usage documentation. Removed vi swp file
|
Had to create another pull request. When trying to squash made a few learnings. :) The new pull request should show as a single commit now. |
|
Guys lets be a little more informative here. What is the iOS version of your app? Because if it is iOS 6 and later (or even OS X 10.8 later) there is no memory leak. And I am seeing "dispatch_release" in your code which I can quote this from documents: "If your app is built with a deployment target of OS X v10.8 and later or iOS v6.0 and later, dispatch queues are typically managed by ARC, so you do not need to retain or release the dispatch queues." So maybe it only leaks in older versions which are not supporting ARC? In this case better test a version of the iOS first then use release. |
|
I have deployment target 7.1 and the described leaks appeared on the leaks profiler. |
|
I'm using XCode5.1.1, building with IOS SDK 7.1 and the leaks appear while running in the profiler. It also seems to address some of our app's long running memory issues. The documentation you are referencing also says: "calling this function on global dispatch queues has no effect." Yet it seems to have an effect... So no real harm either way. The code resolves the largest memory leak our application had, and allows me to pinpoint some of the smaller ones so we're keeping it for now ;) We've been running this code in our prior two app releases. |
|
But that's really interesting to see the exact same development spec with the same version of this library and I have no leak memory. I really care about the memory and I always check it so I didn't miss it. I am using this library heavily in my app and have never had memory leaks. I just can't get my head around the idea of the same environment and some have leaks and some don't. Are you guys using the latest version of this library? tnx |
|
I've been trying to answer the same question for myself. I'm surprised I'm the first person that has noticed this issue. At this point my suspicion is that we are exercising the library in a less common way. Yes I am using the latest version of the library. |
4 participants
During profiling we found a memory leak in our app. The Leak pointed to
how the dispatch_source_t was being managed. These changes seemed to
cleanly resolve the leak issue and are in line with Apple’s usage
documentation.