Please do not post the same thing multiple times. The board software automatically flags certain posts as needing moderator attention. This happens the most often for new users. I'm pretty sure this is made clear at the time you attempt to post. Posting the same thing over and over again just makes that many more posts the moderators have to weed through later. This makes us sad. Don't make us sad. If your post/thread doesn't appear, just wait a while. Don't post it again. If it hasn't shown up by the next day, then you can try again. I normally go through posts in the mornings, and try to check a few times throughout the day, but I'm not here 24/7. There will typically be a significant delay before posts are approved. Just be patient.
According to Instruments->Leaks, there are no memory leaks in the application I'm developing. However, tracking memory usage myself (using task_info and task_basic_info::resident_size) shows that the memory footprint increases when certain operations are performed.
Is it correct to believe the resident_size value over instruments? The only thing I can think of that Instruments would miss is a circular reference situation, which isn't likely for my code. Also, the application will eventually begin to receive memory warnings which leads me to believe that the leak does exist.
Does the fact this leak doesn't show up in instruments mean it's happening in a framework or the OS itself? Is there anything else I can deduce based on this behavior?
You may not be leaking anything. You may just be continuously creating objects, and also keeping a valid reference to them. Hence, no leak.
It's really hard to tell without seeing any code. Can you perhaps post some code where you think the "leak" could be occurring, or at least where you are noticing the memory footprint climb in instruments.
You may not be leaking anything. You may just be continuously creating objects, and also keeping a valid reference to them. Hence, no leak.
It's really hard to tell without seeing any code. Can you perhaps post some code where you think the "leak" could be occurring, or at least where you are noticing the memory footprint climb in instruments.
I may have found part of the problem. It seems that autorelease pools are kind of funky with Grand Central Dispatch. The docs claim that a custom GCD queue will get it's own autorelease pool, but this pool may not get drained regularly.
I have a GCD queue to perform background operations and implement a kind of run loop for it like this:
Before I added the autorelease pool, memory usage would jump up and down, but mostly up, generally increasing over time. After adding these 2 lines around perform_task it seems to behave much better.
The other possible culprit is with AVAssetReader API. AVAssetReader::startReading spawns a thread to do reading operations, and in my "stress test" loop I may just have been starting and stopping reading so fast that the threads that get spawned don't have a chance to catch up and get killed. I'm guessing if these frameworks are implemented in c with raw malloc style stuff (rather than obj-c alloc/retain/release) then they won't show up in instruments.
The reason I suspect the framework is that I was getting similar memory problems even when I changed the loop() function to submit to the main queue. But it could also be the case that the GCD/autorelease funkiness also affects blocks submitted to dispatch_get_main_queue().
Disclaimer: I'm not 100% sure about any of this ;)
Feldspar
Posts: 148Registered Users
Music Visualizer ~ Rabbit Hole || Feldspar Apps home page : http://feldspar-apps.com
Replies
It's really hard to tell without seeing any code. Can you perhaps post some code where you think the "leak" could be occurring, or at least where you are noticing the memory footprint climb in instruments.
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like AwesomeI have a GCD queue to perform background operations and implement a kind of run loop for it like this:
- (void) loop {NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
[my_worker_object perform_task];
[pool drain];
usleep(delay);
dispatch_async (my_queue, ^{
[self loop];
});
}
Before I added the autorelease pool, memory usage would jump up and down, but mostly up, generally increasing over time. After adding these 2 lines around perform_task it seems to behave much better.
The other possible culprit is with AVAssetReader API. AVAssetReader::startReading spawns a thread to do reading operations, and in my "stress test" loop I may just have been starting and stopping reading so fast that the threads that get spawned don't have a chance to catch up and get killed. I'm guessing if these frameworks are implemented in c with raw malloc style stuff (rather than obj-c alloc/retain/release) then they won't show up in instruments.
The reason I suspect the framework is that I was getting similar memory problems even when I changed the loop() function to submit to the main queue. But it could also be the case that the GCD/autorelease funkiness also affects blocks submitted to dispatch_get_main_queue().
Disclaimer: I'm not 100% sure about any of this ;)
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like Awesome