I am using the UIImagePickerViewController to take a photo in my app, but in iOS4+, which supports multi-tasking, I encountered a memory problem. If you've opened a lot of apps, and then mine, the UIImagePickerViewController does not work properly anymore. The picker controller some times get closed without calling the delegate method, sometimes the whole app crashes. Of coz, the memory warnings are already received, but what can I do? Dismiss the pickerController when receiving the 1st memory warning, and alert the user that he has to kill as many suspended apps as possible and retry? This is really not a nice user experience? But if I do not do so, a crash or a sudden close of the pickerController also confuses the user. Did anyone meet and solve the same problem?
UIImagePickerViewController is notorious for throwing memory warnings. If you don't want to be in the business of making sure everything is ready to unload if you get those warnings then I recommend you switch to AV Foundation instead.
This SO answer has a link to a tutorial which may get you started in that direction.
AVFoundation camera tutorial
Related
I'm getting a "Slow defaults access for key ClientState took 0.034635 seconds, tolerance is 0.020000" warning when testing my iOS app - it seems to occur intermittently. I've tried to look around to see what it is about, but I'm not entirely sure! Any help appreciated, thanks.
My best guess is that the first Viewcontroller is taking to long to load.
I never got this message until adding a large background png to the first view controller which now exhibits the same behaviour but all the time. Take out the png and I did not get it on 5 loads.
Guessing same as depicus: first viewController loads too long.
In my case app starts by populating tableView from last saved CoreData. Right after that server tells me authorization has expired, I start re-auth and facebook login view comes on-screen - on top of tableView.
This is were I get that error. Without facebook login, everything is ok == fast enough.
SMSidat - I had the same problem and was looking found forever. I have an sqlite database and upon loading the vc that accessed the database it stated "slow defaults .....clientState took to long to load and all.
Try to remove Auto Layout from your nibs. Once I did that, no more "slow defaults...warning"!! Even though this is from 3 years ago...Hope it can help someone out.
Here is a link to the tread that helped me out
Slow UIViewController load time (slow ClientState warning)
In my experience this is cause by the time it takes to load a view when you invoke it. Take my case for example. I had a TabBar app and in one of my tabs it was a gallery. I was calling the view but within the view I was fetching everything on the main thread (big no no)... obviously, User interaction was gone out the window and the app will lock until done. The phone will take its time to load the images and to present the view. Once I multi-threaded my application and the pictures loaded in the background no more warning. Hope that helps, I am not sure how this warning works underneath but that changing this things got rid of it. :)
I came across the scenario where in if after moving the map immediately if I tap on back icon while the map has not fully loaded
The application crashes.
What I can understand is Since the loading is still in progress and I tap back the the application releases the controller but the google map loads asynchronously in NSRUNloop (not sure). So that might be the problem not sure though.
So does anybody know what can be the issue and is there any way to solve this issue?
Please comment if more description required.
It sounds like that when you close the view, the object that is the delegate for the completed map load has been deallocated, causing the crash with a bad access.
A good way to get to the bottom of these types of crashes is to use Instruments (part of the Xcode suite to tools) and go zombie hunting.
For anyone who is still searching for the answer
What exactly happening was that map view events were getting fired even if the controller was released causing a crash in the app.
So the solution is Before setting the value of objMKMapView to nil you need to set value of objMKMapView.delegate to nil.
So I׳m trying to play some effects in my Cocos2D game using SimpleAudioEngine , but after I have added them my app crashes when it goes to background (multitasked).
I searched for this problem in the internet but all the solutions that I found didn't work for me. What I did find out is that this problem happens because my app is somehow trying to play sounds when backgrounded.
In console it shows me (which is the same error I found other people had):
sgx error (background gpu access not permitted):
And another thing, when I run my app on the simulator, or even on my device while debugging carefully (going line-by-line with XCode while the app is running) this doesn't happen.
I just had this issue. I resolved it by having a bool to check if the app is running or in background that I set to true when the app goes to foreground ( applicationWillEnterForeground ) and that I set to false when the app goes to background ( applicationDidEnterbackground ) . So using the bool you can tell if the app is in the background and if it is, I just exit out of drawView function in EAGLView (thus not doing any graphics rendering which was causing the error).
I am a very dodge programmer but that method has worked for me and I hope it works for someone else. I did not need to unload and reload my sounds or anything and my app now has Multitasking XD
I was experiencing this, on about 25% of the occasions that my application re-entered the foreground. Like you, when I removed the sounds, the problem went away. That is how I came across your question here.
I may have found a solution to this. I have made what appears to be an unrelated change, but the problem seems to have gone away. Now, when my app enters the background, I invalidate my main scheduled timer. When my app re-enters the foreground, I then re-schedule the timer (after reloading my sounds, which I completely shut down on entering background).
So far, the problem has not come back. I would be interested to know if this helps.
I just resolved this issue on my end. Here's what was wrong in my case and, from what I can tell from the other answers and comments on this page, many other people's case as well:
By default, when I started my project, CCDirector::sharedDirector()->pause(); and CCDirector::sharedDirector()->resume(); were both being called twice, once by (void)applicationWillResignActive:(UIApplication *) and (void)applicationDidBecomeActive:(UIApplication *) respectively in AppController.mm, and once by AppDelegate::applicationDidEnterBackground() and AppDelegate::applicationWillEnterForeground() respectively in AppDelegate.cpp.
Make absolutely sure that these methods are only being called once, in AppController.mm. In AppDelegate.cpp, instead make sure that you are calling CCDirector::sharedDirector()->stopAnimation(); in place of CCDirector::sharedDirector()->pause(); and CCDirector::sharedDirector()->startAnimation(); in place of CCDirector::sharedDirector()->resume();.
Hope that's helpful to anyone else stuck in this crappy situation!
Are you sure it's related to audio? "background gpu access" sounds like it's using OpenGL.
I had the same issue in my application and spent some 4 hours to find out. Going background was OK the first time, but crash application the second time. With a short error message related to OpenGL. I had the same questions: how audio can crash graphics. But it wasn't a question of audio, but a question of notifications...
I discovered that going foreground was creating 2 timers in my custom level meter class.
I had registered UIApplicationWillEnterForegroundNotification and UIApplicationWillResignActiveNotification. Then, going background invalidated only one, since I registered only on notification... That was it!
One need's count its notifications!
Occasionally in low-memory conditions the UIImagePickerController I use gets 'stuck' with the shutter closed. Generally when this the WatchDog is allready jettisoning other background apps so within a second or two the low memory condition is over, yet the UIImagePicker controller is still stuck.
Has anyone else encountered this and implemented any sort of workaround or found a way to detect when the picker is in this state, so that it can be removed and a new one put in its place.
Thoughts / Ideas / Solutions??
Have you tried allocating (and then freeing) a megabyte or two of memory using malloc() before starting the UIImagePicker? Or claim it slightly earlier in your app, and then release it when you want to show the picker.
I guess you should be able to see roughly the amount of memory UIImagePicker needs to run successfully by running your app inside of instruments.
Whilst not ideal, it should cause other apps to be given memory warnings earlier on and hence the UIImagePicker should then have enough memory to run.
That's a known behavior of the camera application too. I guess you can't do anything to it except freeing as much memory as you can before starting it. You could raise a memoryWarning yourself so every application will receive it and start freeing memory but I have no idea how I can do that. I started investigate sending the notification myself (UIApplicationDidReceiveMemoryWarningNotification) without success. I guess we need to send an object along the notification to define the warning level but I'm really not sure.
I've developed my application using my 3G device to test with. Upon giving this to a friend to test, he's noticed that it crashes..I've had a look at the crash log, but it's not much use except for the "EXC_BAD_ACCESS" statement after a few memory warnings.
On my device, I can use the imagePicker lots, and each time a photo is taken I get a memory warning, but this doesn't cause any problems.
On my friend's device (also a 3G), after a couple of images chosen from the camera, the app crashes.
So, my question is.. I think something is being deallocated because of the memory warning - but only on my friend's device, and then after deallocation, it's trying to be used again. How can I find out what object is being called? I can't use NSZombies because this is a remote (beta) device.
Help please!
Also if anyone has any ideas why my device can pick image after image without any problem and his can't...that would be most helpful
Thanks!
EDIT: New discovery.. I'm getting this error message too: KERN_PROTECTION_FAILURE which I understand to be something to do with data access. The crash seems to happen right after I save the image got from the UIImagePicker. Any ideas?
You may be over-releasing something. If you're running Snow Leopard, run the Static Analyzer (Cmd-Shift-A) and look for memory errors.
The fact that it crashes after a memory error suggests that a UIViewController has released its view. Do you have any UIViewControllers that observe NSNotifications, or otherwise might change their IBOutlets while they are off-screen? This is a common cause of this kind of crash. Make sure you're correctly memory managing your IBOutlets. UIViewControllers should never mess with their IBOutlets (or their UI components at all) when they are off screen. Even if you don't make this mistake, if you're not implementing things as noted in the above link, you can still crash after memory warnings.
MemoryWarning was a pretty good idea, and things have improved, but Apple still hasn't quite cooked all the issues around how it plays with UIViewController. The developer still needs to be very careful.
You should have your friend come to your computer and run it with NSZombieEnabled. That's the best way to debug these issues.