"Received memory warning" when using NSThread in ios - ios

I am developing iPhone App. i am using NSThread for continuous calling of function which contains C++ code.
when i use NSThread or dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),^{
Function calling
}
then it gives me "Received memory warning" warning after 5min and crash the application.
but when i run this function on main thread/Queue then it works perfactly.
also i have tried Xcode profiler for check memory leaks but no memory leaks found.
how can i resolve this issue?
thanks in advance.

Instruments may not see all memory leaks especially if you are calling some C code as you are by passing the retaining functions.
It's hard to give you an answer without knowing what your thread contains but you may want to check your code for unreleased object / mis-deallocated / destroyed objects.
You should also check that you are not creating a whole bunch of threads (NSThread) and that they are correctly releasing their contents after termination.
By the way, your app shouldn't terminate when receiving a memory warning, it's a normal message coming from the OS. Check your deallocation when viewWillUnload / didReceivedMemoryWarning functions are called.
You should also try to create memory warning manually using the simulator

I had a somewhat similar problem using a NSOperationQueue on a background thread.
Assuming you have already declared you mandatory NSAutoreleasePool in the function, you could try to allocate/release the objects yourself and don't use autorelease unless necessary, to make sure the memory is freed right on time.
A second advice would be to use Instruments and Allocations, to see what exactly takes up your memory. Probably you have some object being retained and not released when it should be. This post is AMAZING when it comes to this http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ and you might also find some useful info here http://www.cimgf.com/2008/04/02/cocoa-tutorial-fixing-memory-leaks-with-instruments/
Otherwise... you need to post more details.
Good luck!

Related

didReceiveMemoryWarning: what type of memory?

I have a base cordova app, with some objective-c code around cordova's framework. Sometimes I've didReceiveMemoryWarning notification, but I don't understand if the problem is the javascript inside the UIWebView or other.
The documentation says:
Your app never calls this method directly. Instead, this method is called when the system determines that the amount of available memory is low.
But my question is: what type of memory?
RAM? Heap allocations? Something else?
RAM, it is for RAM, if your app consuming more memory without realising it, and no memory to remain to process any more thread then, this didreceivememorywarning get called by system.
You should profile your app with Instruments and you'll get a better picture of what's consuming memory.
The memory issue represents to RAM, generally we are creating the app using different objects, and these objects take some memory to process the required task. If we aware about them we can easily manage the memory but sometimes for beginners it is not managable to debug the memory, and didReceiveMemoryWarning occured. We can diagnose or debug this issue by instruments.

How we can check that certain object is released memory

As I start working in swift, I am curious in memory mgmt. As we all know that during any object creation or assignment of data into that object it takes memory. How can we check that a particular object has released the memory. I used xcode memory report to see memory status and fluctuations.
Here is a sample of images:
How can release memory if I already set nil into the objects.
Use instruments to track the lifecycle of an object than just Xcode because it gives you the allocation details at much higher level.
Check out the answer at https://stackoverflow.com/a/14891837/5133769. Though it was explained with old instruments it still works.
Some objects are very small and it could be difficult to see in Memory profiling which one is released. This tool is helpful for finding memory leaks in an app. To check was some object released from memory or wasn't you can setup breakpoints or logs in dealloc() method for objective c and in deinit() method for swift.
Using instruments checking for leaks or allocations is the recommended way.
You can also set breakpoints or add logs to the dealloc method.

Potential Memory Leak in iOS

So I just made an app that loads a map with some markers on it. The app has a navigation controller that segue from the main screen to the map and back. While running the app on my phone and simulator i noticed that if i went back and forth between the home screen and the map, the amount of memory that the app was using just kept growing indefinitely. Is there way to assist in the process of memory management (i know the system uses ARC)? Im using the google maps sdk btw.
Thanks!
Does it cause the app to run out of memory and crash?
Or is it using a ton of memory, receiving a memory warning, and dumping said memory?
So, unless it is causing crashes, it may be behaving correctly.
Apple has extensive and well-documented support for diagnosing these kinds of problems. See "Locating Memory Issues in Your App".
Check your codes where using NSThreads and GCD blocks. If there are some places you create plenty of threads, it is recommended to add a autoreleasepool block.
Memory may leak in these situation:
If you are writing a program that is not based on a UI framework, such as a command-line tool.
If you write a loop that creates many temporary objects.
If you spawn a secondary thread.
For reference: Using Autorelease Pool Blocks

iOS : ARC, not freeing memory

I've kind of a weird issue with my iOS app.
after a while my app goes low in memory so memory warning, everything seems to be fine, but when I check the memory usage I noticed that all the calls to viewDidUnload didn't free up lot of memory, so after a few click in my app, it goes again in memory warning, everything seems to be fine again, but not a lot a memory have been released, so it goes again in memory warning faster, and then it crash (after the third memory warning most of the time). this crash is random : app freeze, app leaves, my debugger says app paused, but no bad access or sigbort, no zombies.
my guess is that memory warning can't free up enough memory has it should.
(I checked all my viewDidUnload and make nil every objects that are allocated in viewDidLoad)
Any help will be usefull !
thanks a lot.
So I managed to work with my issue.
I wrote "-(void) dealloc" methode in all my controllers and check if I enter in it as I should. (on pop controller, dissmiss etc..)
Every time it didn't, I do step by step in the controller to see what was retaining my controller from beeing dealloc.
most of the time it was some property that was not in "unsafe_unretained"
delegate that was in "ASSIGN" (and should not be in assign but in unsafe_unretained)
(heritage from non-ARC project...)
I also had some strange controller with XIB that was not deallocated even if empty.
I rebuild new one step by step with copy/paste and finaly with exactly the same code, the new controller was released, with no visible difference between then !!! gnneee
at least I know how to debug that kind issues now...
I don't think there's any way to give a specific answer without more data so the best I can do is suggest that you stop guessing what might be happening with your app and learn how to measure what is actually going on. Run your app under Instruments and you'll be able to check for leaks and also actually see what classes are responsible for the most of your application's memory footprint.
You should make sure you know how to use both the Leaks instrument to identify leaked object but also the Allocations instrument to identify orphaned (but not leaked) sets of objects which should have been released or just cases where your app is not responding to memory warnings as you expected.
https://developer.apple.com/library/ios/#documentation/developertools/conceptual/InstrumentsUserGuide/AboutTracing/AboutTracing.html might be a good place to start and there are a number of tutorials available as well; http://www.raywenderlich.com/2696/how-to-debug-memory-leaks-with-xcode-and-instruments-tutorial and http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ are among the first results I saw.
Vassily,
First, if you aren't yourself releasing extra memory, the the -didReceiveMemory warning does you no good and the OS will keep asking for memory until you are killed. This sounds like it is your problem.
Second, if that isn't the problem then you are probably getting terminated due to the size of your resident memory partitions. Make sure you look at your VM allocation in Instruments. I expect the MALLOC_TINY or MALLOC_SMALL both have greater than 5 MB resident and dirty footprints. Due to the nature of small allocations these VM regions will never shrink. The only option you really have is to not create a lot of small items in the first place. This is really only something you can address by changing you code's algorithms to use less memory.
Andrew

How to detect stuff that has not been released properly

Writing a program for the iphone. Realized that I forgot to release an object, but there was really no indication that the object was not released everything just worked.
What is the best way to track something like this down? Is there a way to see what objects still exist in memory when the program exits out?
Take a look at the Leaks tool in Instruments.
Strictly speaking, when the program exits, it doesn’t matter what you’ve left in memory: the system frees everything that your application allocated throughout its lifetime. Since iOS 4, though, apps usually just get frozen in the background and don’t exit until the system kills them to free up memory. To avoid that—and to reduce your app’s memory footprint, which is important while it’s running—you should, as highlycaffeinated and Daniel suggested, use Instruments’s Leaks tool to check for objects that aren’t getting deallocated properly.
When the app exits, anything in memory is destroyed by the system (not deallocated-- but just outright destroyed when the address space is given back to the system).
While others have suggested using the Leaks tool to find leaks in your app, Leaks won't find many many kinds of memory accretion. If an object is allocated, shoved in a cache somewhere, then the key to that object in the cache is lost, the object is effectively leaked (can never be used again) but won't be find by Leaks because it is still connected to your viable object graph.
A better bet is to use Heapshot analysis to see how your app's object graph grows over time. I wrote up a tutorial on using Heapshot analysis that you might find useful.
If you want to grab a snapshot just before your app exits, then put a sleep(1000); into your code in either an application termination handler or somewhere else that is executed just before the app exits.
Just remember to remove it before shipping a production build. :)
Once an application quits - you don't have access to that. But Instruments (an XCode tool) can look for memory leaks.
Nothing exists in memory when pprogram exits. But you can start with analyzing your code (Product -> Analyze) and running it with (Product -> Profile) Allocations or Leaks in Instruments to find memory management issues.

Resources