I developed OSX project in objective-c. I disabled ARC and I dealloc(release) memory manually. Is in xcode any tool, which can show me that I forget release any objects?
Nowadays i would recommend using ARC. But back then, when it wasn't available, the Profiler "Leaks" Tool did a pretty good job for me. You can see total allocations and potential leaks there.
You can start it by clicking Product --> Profile --> Leaks .
That's doing a analysis on runtime.
The Product --> Analyse Tool can analyse your code statically and show up further potential leaks (The arrows it draws can be a little confusing at the beginning).
Use the Profile menu item in Xcode and select the Leaks instrument.
Yes, you can use Instrument for that.
XCode-->Open Developer Tool-->Instrument.
Check out :
https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingLeakedMemory.html
and
https://developer.apple.com/library/tvos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/
Related
Our app is good to go and everything seems to work just fine. We have tried to manage the memory as much as we can and we have no crashes at all.
Now before release, I want to check if there are leaks, or some problems that may cause my app to be rejected by Apple.
What's Apple's policy on memory leaks? Are even small ones not allowed? If some are allowed, then what's the limit?
What software/tool should I use to check memory management/leaks, to be sure that if it gives me good results, my app will be approved by Apple, if simply not crashing is not enough?
Is there a guide about one of this tools ?
Is checking my app in all iOS versions in the iOS Simulator enough? I have only 1 iPhone 4 :)
What you can do:
Run "Analyze" (MenuBar -> Product -> Analyze or SHIFT+CMD+B)
This checks your code for possible leaks and dead stores
Run "Profile" (MenuBar -> Product -> Profile or SHIFT+I)
This runs Instruments which allows you to track your allocations and possible leaks at runtime.
I don't think there is a specific policy about leaks - but a program that leak will crash - and Apple do reject apps due to crashes.
Otherwise I do agree with MatzeLoCal - run Analyze, and fix everything - and run a lot of profiling if you suspect there to be any issues.
In addition to running Analyze...
There is a tool in Xcode called Instruments that allows you to search specifically for memory leaks in your application. Choose the Leaks option when prompted when you open Instruments and then mess around in your app while recording to see any memory leaks that may be hiding in your app.
Here is the official Apple documentation for using Instruments: https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingLeakedMemory.html
I am learning Xcode and objective c, but the book I am reading is using the older version (3.2) of Xcode. One chapter, which is completely dedicated to memory and leaks, says I need to turn on garbage collection through Project Settings > Build. However, I can't find the garbage collection setting. Has it been removed or am I just missing it?
Xcode 4 still has Garbage Collection, all you do is go into your project (the top option in the navigation bar with the big xcode project icon). Select your target which should just be the name of your app with the application icon next to it. When you select that, along the top there is a bar with different options, such as summary, info, build settings etc. Hit "Build Settings" and type "garbage" in the search field. Then set garbage collection to required.
One very important note about GC is that it is officially deprecated as of Mac OS 10.8, which means you should be transitioning your code to ARC if possible because GC might not be around for much longer.
Update: See other answers for enabling GC in current versions of Xcode. As I stated above, you should be transitioning to ARC if you haven't already.
As of XCode 4.4 the garbage collection build flag is user defined (see the very end of the build settings list).
GCC_ENABLE_OBJC_GC supported
Valid build settings are:
unsupported: The application cannot load code that requires garbage collection. The loadable bundle cannot be loaded by an application that requires garbage collection.
supported: The application can load code that supports or requires garbage collection. The loadable bundle can be loaded by an application with any level of garbage-collection support.
required: The application can load only code that supports garbage collection. The loadable bundle can be loaded only by an application that supports garbage collection.
Garbage collection is very much fully supported in Xcode 4. Xcode 4, itself, is a GC'd application.
GC is also very much not available in iOS. If you are writing an iPhone/iPad app, you can't use GC.
That's a challenge but you might be able to get it done - here's a starting point to think about in relation to PDF generation:
iOS SDK - Programmatically generate a PDF file
If you can generally follow what is going on there, you might be OK.
Xcode 3.2 is still available for download - in fact, 3.2.6 was released within the past week or two, so it's not exactly "old and busted." :-) Xcode 4's interface is very different, so given your tight schedule and your need to start from square one, you might be better off using 3.2 for now. That will certainly make it far easier to use the book you have.
As of Xcode 4.3.3 the only setting available for parameter "Objective-C Garbage Collection" under section "Apple LLVM compiler 3.1 - language", Build Settings for your target app = "Unsupported"
I'm currently migrating the Fragaria framework from a GC-only environment to GC being supported. After the work was done (or what I thought had to be done to make it work) I was able to run the examples that come with the framework without any problems and Instruments didn't show any major memory leaks.
I included non-GC Fragaria in my non-GC application and it crashes as soon as I place the cursor on it. To be honest the usage pattern is different from the examples as I'm embedding it in an instance of NSViewController instead of NSDocument.
Can you give me some tips on how to debug this? I'm a bit lost on where to proceed now.
First thing to do is Build and Analyze the code, then fix any problems it finds.
Next, try running with Zombie detection enabled (google NSZombie).
Finally, each crash's stacktrace should give you a pretty good idea where things have gone off the rails.
Can anybody explain debug and release modes in the iPhone SDK? What is their importance and how are they distinguished?
A debug mode is when the compiler keeps debugging information for use with the debugger. It also doesn't optimize the code, as optimizing can make debugging tricky.
Release mode takes out the debugging symbols and turns on optimization. It's generally done when "releasing" the product, since you want it to run as fast as possible.
I am getting close to finishing the release of my application and are trying to use Instruments to fix any memory leaks.
How come that I can spot one memory leak when using Instruments and my device but not when I am using the iPhone simulator? I understand that this is a high-level question, but I don't think posting any code would help anyways (quite a bit of code...).
And is it possible to get instruments to point to the source code where it think the leak is? I can do it when using the simulator, but it seems like it doesn't work when using it for the device (objects are represented by the address (I assume) while running it for the simulator it sees what object it is, setup issues?)
Thanks in advance!
Regards,
Niklas
Update: Could it have something to do with that OSX is having automatic garbage collection but iOS doesn't?
Trust only the device. That's what your user will use to run your application.
Don't trust the simulator.
As a demonstration of this, I just intentionally added a leak to a project. The leak was not detected while in the simulator, but showed up as expected on the device.
The simulator is just that: a simulator. It can be useful to work faster, but is never a replacement of the device.
Once Instruments showed you a leaked object, you can double click on it. It will show the part of your code responsible for the leak. This works for the simulator and the device.
When you compile for the device, make sure you are in debug mode (and that the settings for this mode kept all your symbols).
Some more tip that you might find useful:
For a more fluid session, disable the "Automatic Leaks Checking", and manually press the "Check for Leaks Now" button when appropriate.
The "Build and Analyse" command will do a fantastic job to help you find leaks. It's not (totally) magical, so it won't find all leaks. For example, iVars leaked won't be identified. But for the scope of a method, it's just awesome.
I highly recommend to activate the "Run Static Analyser" flag in your build settings (or only for the Release mode if you have a slow to compile machine).
If you want more info about how to use Instruments to find leaks, read this Apple doc: Instruments User Guide: Built-in Instruments and Instruments User Guide: Viewing and Analysing Trace Data > Looking for Memory Leaks
You can also watch the video of the WWDC related sessions.
If you still don't understand where your leak come from, it's time to (re)read the Memory Management Programming Guide.
Thank you for wanting to ship a leak-free application. With iOS 4, it's now more important than ever.
If you haven't already take a look at the handy "Build and Analyze" option in the build menu. It will run the static analyzer which generally does a great job. If nothing turns up with that you should could some time reviewing the WWDC session videos on Instruments.
There is no substitute for profiling on hardware and with the debugger and instruments connected you can get everything you would in a simulator context.