Well, while running my iPhone game on my iPhone 4 through Xcode, my app crashed (sometimes does, sometimes doesn't), and when it crashed, Xcode didn't throw me any info. In the log, I could see (gdb) written, but nothing else that could help me find the problem.
What could cause such an error? At least it should tell me something, no?
Crashes without explanation on the device itself are often due to using up too much memory; the device simply terminates the app when it has requested more memory than available. This is easy to do in game development, with all those images.
Use Instruments to track memory usage, and/or put some good memory management code in the App Delegate methods for memory warnings and always release as much as you can.
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'm put together a CoreMIDI iOS app where I'm testing MIDINetSessionBrowser and MIDINetworkSession. I've been looking at this for a while now, and it appears that CoreMIDI has memory leaks.
Also, I just tried Pete Goodliffe's CoreMIDI objective-c demo and it also generates memory leaks when I run through profiler!
Thus, I think the chances that I'm missing something are smaller :)
Has anyone else profiled CoreMIDI and found the same?
Note: I'm using latest XCode and latest iOS and profiling by running on iPod touch 4 device.
I've some memory leaks due to CoreMIDI too.
It appears that the same issue still remains on iOS 5.0.
By the way, I'm not using PGMidi classes, but only the CoreMIDI API.
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.
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.
I have an iPhone app that, for some users, sometimes behaves as if with the main UIView has been removed from the view hierarchy. It always happens coincident with a significant event in the game. Other Core Graphics-drawn UIViews that are above it in the z-order remain, but the main one (an OpenGL view) appears to be gone, leaving the background (a solid color).
The app does not crash (it keeps running, without the view), and this seems to happen very consistently for affected users. Unfortunately I am not able to reproduce it.
I suspect a memory issue -- that would be the easiest explanation -- but based on my reading it looks like didReceiveMemoryWarning only deallocs views that aren't visible, and aside from that the memory usage for my app is pretty small. Also, the "significant event" only results in OpenGL drawing and a SoundEngine call -- no view manipulation.
Anybody out there seen something like this before?
Yes, infact one of my applications very occasionally exhibits this problem and it does seem to be memory related.
I have had no success tracking it down either by debugging or analyzing the program flow. I have verified that the view in question is destroyed and not just hidden in some way.
It happens so infrequently that I haven't looked into it to deeply, but I do think it's caused by something in the OS in some way,
You can easily test low memory in the simulator to debug this problem if it is memory related.
The problem ended up being an uncaught NSException (from a third party library) thrown in the app's timer thread, which killed the timer thread but not the rest of the app. The good news is that crash reports are generated in this case, which can make tracking it down much easier if you know to look/ask for them.
As is made clear in the SDK documentation, when your app is running low on memory, views that are not in use can be collected. When it's needed again, it's re-created. This is to conserve precious iPhone resources. Your best bet is to retain the view so it can't be released.