I am attempting to obtain information on possible leaks that exist in the iPad app I am currently developing. Typically when Instruments finds a leak, a red 'peak' appears on the graph within the leaks section and I am able to obtain information on that leak within my code. Currently, Instruments is instead telling me "Leaks Discovered", but there are no peaks on the leaks graph and no details are shown. Any idea on why that might be?
Not sure unless there's more information but I generally use "Build and Analyze" and fix all the leaks it shows there and only then move on to Instruments. Try Build and Analyze to see if it shows any leaks there. If you're using Xcode 4, its just Analyze under Product.
Related
I just got the new xcode and the tool I used to test for leaks isn't there under run anymore? Can someone tell me how to test for leaks?
Instead of having direct instruments in the menu, you start the app using the "profile" option and it asks you which instrument you want to use - there are the instruments you used to see, including Object Alloc and Leaks. There's also a very useful Zombie tool to help with over-released objects.
I have an app that is crashing on the device (works well in the simulator) which leads me to assume that maybe it's a memory issue...
When it crashes, there is no message whatsoever reported in the console.
It does not crash each time a certain action is taken, it crashes at different points of time always after the app has been running and in use for some time.
I know I'm supposed to ask a more specific question - but if anybody is able to tell me where to start trying to track down a crash that does not report in the console, I would really appreciate it!
I am now using the latest version of XCode (4.2)
Thanks in advance...
It very-well could be a memory issue. If that is where you want to start your diagnostics, you can use the built-in Xcode profiler. In Xcode Product->Profile will get you started.
Maybe setting the NSZombiesEnabled value to YES in Project -> Edit Active Executable -> Arguments -> Variables is also helping; this will show you memory access errors based on accessing released objects. But in that case you should at least get a SIG_ABRT or BAD_ACCESS error ...
You can also log when the app receives a memory warning in the didReceiveMemoryWarning functions of your view controllers - this is called before the system is throwing out stuff when memory gets low. That of course could lead to a crash with nothing showing.
First, relax.
Then read this Technical Note.
Now, follow these steps:
From /Users/<username>/Library/Developer/Xcode/DerivedData remove all folders.
From /Users/<username>/Library/Application Support/iPhone Simulator remove all folders.
Clean your trash.
Remove app from device.
Build and run application on device.
Follow the steps that leads toward a crash.
Now, go to XCode->Window->Organizer and select "Device Logs" your device from the DEVICES pane. Select the most recent of these which has your application's name. Wait for XCode to symbolicate the crashlog. There are two possibilities now:
Its a low memory crash.
Its a memory management related crash.
If its option one, profile your application in Instruments.
If its option two, you should see the stack frame where you application is crashing (or your module's stack). This SO question will be very helpful
If you cannot understand the output (or you think the crashlog is not symbolicating - or that its not your code that's crashing), please post the crash log's crashing thread's stack here and I'll look into it.
PS: in the first section we do the first two steps to make sure there are no left-over .app/.dSYM files which might hinder symbolication later in the process because XCode symbolicator is not that intelligent.
Is there a list of known leaks within the iPhone SDK sitting somewhere, all alone?
I guess you would have it specified by version. (I just ran my test app - it has a leak outside the project itself (somewhere related to connections) when testing it on a v3.3.1 iPhone 3G, but the leak is not there using an iPhone 4 v4.0.2.).
It's doubtful that there's a public list of known memory leaks. If you want to know whether your leak is a known issue, your best bet is probably to search Open Radar, or to use Apple's Bug Reporter and see if you get a response.
During my short experience with the iPhone SDK, I have never encountered a memory leak caused really by the SDK. It is mostly caused by your code but has shown itself later.
It is also possible that the new SDK has improved some ways of doing things, so that your previous leaks do not occur anymore.
You need to give more details to the leak in order to help you.
First, Thanks to all for your quick help for any questions asked in this forum.
I just want to know what are the testing tools coming up with Xcode on Mac as i need to test my iPhone application professionally (or) What do you suggest to use debug and test my application using any (or) built-in tools?
Thanks.
The first thing I try is Xcode's "Build and Analyze" menu command.
Next thing is to run Instruments and look for memory and object allocations and disposal. Instruments should keep you busy for quite a while as it can provide you a wealth of information, including network performance and graphics utilization.
When using instruments, the first method you should check is memory allocation and leaks. When your application leaks, it will spike. Click on this leak and then extend the details to find the exact whereabouts of the leak.
However read the documentation on it all first.
Documentation
I am trying to run the memory leak program in conjunction with my iphone device. The program says that there are leaks however it doesn't give me details.
GeneralBlock-32 No stack trace available.
How can I set up the leak program so it actually works with my iphone to give detailed information like it does in the simulator.
If you are running in Release mode, the compiler will not generate any debug symbols to map the calls back to your code.
if this is the case, changing your build type to Debug mode will provide you with more information about the leaking area of your application.
I have also noticed that the Frameworks tend to have memory leaks of their own, so it could be a leak from the framework.