I have an issue in my application. My iPhone application crashes at mid of running or during the application launch at times both in iPhone and simulator.
I know that memory management is not proper or is it because of some other reasons.
My application is using a web service that pulls the data and displays it in the view, the web service is working properly because i see the data coming from the web service into my app.
Can anybody suggest how to manage memory properly i.e. where i have to release the objects,what are the objects that has to be released and the objects that should not be released.
You can start by reading Apple's Memory Management Programming Guide and this article might also be helpful.
If you can provide some code that might be causing you problems, you should share it here for further assistance.
Sometimes an iPhone app crashes if you put too much code into init or applicationDidFinishLaunching. This has happened to me when I put too many download queries into applicationDidFinishLaunching and the app simply quit after a while while never showing my interface because it was simply overloaded with tasks. Try moving all the webcode into a separate selector and then calling performSelector:#selector(loadMyWebCode) withObject:nil afterDelay:1] into applicationDidFinishLaunching, then it should work.
Related
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.
I have ported a library (ice , NAT traversal ) for iPhone and encountering issue while actually testing it on iphone device(Version 4.3). Developed a cocoa touch wrapper which is linked with my library. The library routines get called from "test" button placed in my application.
The application is .mm and library is C++ based.
Below are the cases in which my application fails/passes
Case I: I "build and debug" / "build and run" application from Xcode for iphone. The application works fine on iphone and I am able to see logs for the same on the console on my mac machine.
Case II: I try to run application from my iphone, but it just crashes while opening.
Case III: I build and debug application from Xcode, the application get's launched. But as soon as i unplug the debug cable (attached to iphone from my mac), the application get's crashed.
The size of application is 16 MB, and size of library is 288 MB.
I tried to simulate same issue by making a simple test application and a test library. it runs fine in all cases without issues. What can be the issue?
It seems that the application is mapping library code from mac machine while running on iphone. and once the physical link is broken, the app crashes.
size of library is huge?
Thanks in advance
iOS kills apps that blocks the main thread for too long. So that may be the problem and also explains why the app doesn't get killed in debug mode.
Try running your function in the background and see if that helps!
Finally I got answer to my question! Thanks a lot Martin for pointing out "iOS kills apps that blocks the main thread for too long"
Following is the procedure i followed to find the resolve the issue:
Xcode "orgainzer"--> "Device logs" section shows iphone crash report. My application crash report was also generated in the same.
In crash report it was clearly written "mytestapp failed to launch in time" and further it showed the API which was taking too long to return the result. ( in my case it was getlocalhostname API).
I just corrected the API as per my requirement, compiled and run the app on iphone device and it worked!! Also the launch time of application is pretty less now.
Thanks again!
I have an app that I occasionally receive support emails for that say the app crashed on them and won't open up anymore. It shows 'Default.png' then exits. Even when the app is deleted and reinstalled.
-I get no crash reports or memory issues (as reported by itunes connect using reports from a significant sample size >20k downloads)
-I've confirmed it's not limited to a specific model and not caused by jailbroken devices.
-The app doesn't have external dependencies, so why would reinstalling it not fix the problem?
What kind of problems could cause the crashing to go unreported and be persistent?
If you have an uncaught exception handler, depending on what you have in there, you will not get reports written out the same way, or at all, as if you did not have a handler. This will make iTunes think there is not any crash reports at all. Uncaught exception handlers are commonly added as part of analytics frameworks, or third party notification tools.
While this could answer your question, a more reasonable explanation is that the crashing devices just need a device restart.
I think every app developer with a sizable install base has struggled with an issue like this in the past.
Are you using any sort of analytics package, such as Flurry, that helps you report crashes? We used Flurry with much greater success over Apple - Apple won't start reporting crashes to you until you have many -- and "just a few" is never enough.
Additionally, if it shows the default.png and crashes, take a hard look at your start-up code. Are you setting something in NSUserDefaults, that if, corrupted, could cause the app to crash on startup?
Admittedly it is strange that a delete-and-reinstall doesn't do the trick.
The users aren't reporting the error reports to Apple. The crashes could come from any number of sources.
You could walk a user through the process of digging crash reports directly out of iTunes during the next Sync and email them directly to you.
You could try asking a user to delete the app from the device, reboot their device, then have them install the app again after a fresh reboot.
I'm whipping up a short specifications/requirements document for a small prototype iPhone app project. Describing the basic functionality and behavior is not an issue for me. But, since my mobile application and iPhone development knowledge is very weak, I'm not really sure what else should be in such a document regarding best practices and such.
Example: In my programming world (server side Java), when spec'ing a project for outsourcing, I state that the project must pass static bug analysis by FindBugs.
Example: I understand that there are API calls Apple does not want app developers invoking. These can be cause for having an app rejected from the app store. But I'm not sure how to say that we want Apple's guidelines respected. (I don't even know how to test for that.)
What should I include in a two-page requirements and specification document that is specific to iPhone app development?
These are some points you can mention
1. The application should be developed based on Apple's user interface guidelines
2. There should not be any private API call inside the project which makes the application rejected from apple
3. There should not be any memory leak or excess memory allocation issue during the application running state
4. The application should be supported in all iOS after [your option]. (It mainly depends on the features used in the application)
5. The application should be supported in iOS 4
6. The application should work properly on iPhone 4
Hope this helps
A private API wont be mentioned in any header file or in the documentation so one way to test for that would be to manually go through the source files and search for the functions used in the headers and documentation to see that they are there. It's really not feasable if the project grows but for a small app it could work :)
In addition to the things already mentioned here, I'd add a few more:
The app should work fast, no action should give the user the feeling, the device is doing something
Everything that takes a while should be run in background and even better, be cancelable
Make sure you use animation only where it makes sense but not too seldom. A smooth feeling is most important for users.
These things also imply that you try to minimize application startup time.
There are often tricks to work around performance issues. The feeling a users gets from your application is not how fast it is, but how fast if feels. In my opinion this is the single most critical requirement, besides obvious ones like no crashes etc..
What's the problem with using a private API?
Moreover, I would add that it will be tested on iPhone 3G, 3GS, iPod, 4, all with iOS4 and 3.
After submitting our application several times, we continue to receive the following response:
Thank you for submitting My App to the
App Store. We've reviewed your
application and determined that we
cannot post this version of your iPad
application to the App Store because
My App is crashing on iPad running
iPhone OS 3.2 and Mac OS X 10.6.2. My
App crashes upon launch.
Unfortunately, crash logs have not
been generated.
However, resigning the same build with the AdHoc entitlements and loading the build onto the device yields no such crash. After a number of attempts, the application simply does not crash as reported by the reviewer. Furthermore, the reviewer does not provide any useful logging that may have been generated by SpringBoard such as an exit status or event if it had worked properly for any other device. There are no calls to explicitly exit or quit the application in the code line and yet the application terminates on startup.
What might cause an application to terminate in such a manner?
Under what conditions is an application tested that might not be found under a development environment?
Could it be a result of a signing issue that the submission validation system is simply unable to catch?
Thanks in advance.
After fighting with this for weeks, the application has finally been approved. The key: signing corruption. Hence why the application would start (or at least appear to start by showing the splash screen) and then suddenly vanish without a crash log. It failed Springboard's preflight sighing check.
A good tool to keep in mind to check for signing issues. It tells if the application has a valid signing:
codesign -vvvv MyApp.app
When I built the application, I would cp it to a network storage device where our product manager would pull it down and submit it to Apple. If decompressed on the NAS, the code signing was valid. But if you coped the compressed application back off the NAS and validate it, it would fail.
The lesson: make use of the new XCode utility to submit applications.
A few suggestions:
Try to use the leaks tool of the static analyzer to see if there are any memory leaks or problems your not seeing.
Does your app use a web service? This happened to me one time because the day Apple was reviewing the app the web service went down. That cause a crash. If thats the case you would want to add something to catch that.
Finally, In the logs Apple sent you did they send you the dsym file? If they did you can run atos from the command line and it will convert the address to symbols. That will show you what thread and symbol it's crashing on.
Be sure you test with a variety of settings: with Wifi disabled/enabled, with 3G disabled, Airplane mode on/off, location services disabled, etc.
As a last resort, assume there is a problem in your code that executes at startup. Remove half your startup code, set your release date in the far future (just in case it gets approved), then resubmit and see if they have the same problem. If not the problem is in the half you removed... it's a binary search.
I think you have two options: try harder to reproduce the defect using the tools other people are mentioning or to catch those crashes in the field.
PLCrashReporter will trap on an uncaught exception and store all relevant information. Next time your app is run, it can send the crash report that you can then symbolificate and view a stack trace of.
Ouch! That's a tough one. I've had this kind of thing happen before, but it seemed it was reproduce-able when I switched to a different device (iPhone 3G vs 3Gs, etc.). In your case though, it sounds like you're iPad only, so that might not help. There's a difference between 3G and Wifi, I suppose, but I would be really surprised if that was causing a crash on one and not the other.
One thing you could try if you think Apple's not doing their part is to change the binary name and re-submit it under another app name/record. See if you get the same response. If you get the same reviewer, you might, but I think there's a good chance you would get a different reviewer with a new app. Just set your app release date to some time in the distant future and it will never actually show up in the app store if they approve it. If the new app comes back rejected for the same reason, you've got work to do, but if they do in fact approve it, then I would get on the phone with them and point out the discrepancy.
My approach would be to make sure that the compilation is absolutely clean both in the static analyzer (this is NOT optional, it will save you time!) and for the build itself. Then set everything as described on CocoaDev' NSZombie page. Then make sure you have an iPod running 3.2 (actual hardware, not simulator) and test, test, test. Do it with network available and not available, with the device nearly full and freshly restored, every other variation you can think of. Run it with the debugger active and as a release build disconnected. Use Leaks, Instruments and all the other tools to peek in there and get a better feel for what is happening. If you exhaust every possibility you are going to have to beg for more detail from Apple but I bet you find a problem - one of the most important things in debugging an issue like this is to try to forget everything you think you know for sure and start at the beginning.