Pretty simple bug:
Pressing any key on my Mac's keyboard causes an "EXC_BAD_ACCESS" error to occur when running an app on the simulator. Unless I'm entering data into a text field that is, where it works fine.
-
Not sure if this is a bug in my app, or somewhere else. If by some chance, someone was using a bluetooth keyboard with my app, then I don't exactly want it crashing willy nilly... small chance I know, but I'd still rather fix it if it's a bug. I've enabled zombies - doesn't tell me anything about where the crash is occurring, and the app still crashes.
Any thoughts or answers are much appreciated, thanks :)
Turning off "Auto-Correction" in the simulator keyboard settings fixed this issue for me.
Screenshot of Keyboard Settings in Simulator:
Seems there are still bugs with the simulator.
This bug is usually attributed to trying to access an instance that has already been released. Check your instances, anything that you allocated, released, and then you are trying to access. It may not even be connected to the keyboard, but maybe a delegate method. Post some code so we can have a better idea of it. For example, the code for the view controller that is running at the time of the crash.
Try to run your app with "Guard Malloc" on. You find this setting when you go to
Manage Scheme -> Run app (on the left side) -> diagnostic (on the top
lashes) -> under Memeory management.
This will show you the crash point where it happens and you should be able to find the reason much more easily
Related
I have an app where I have 5 sets of animations that I'm storing in an array. The animations get picked to play randomly after a button touch. This is all working perfectly, however I noticed a bug when I quit the app and reopen immediately, I'll see my main view, then it'll jump to my second view that has the animation in it. (This shouldn't happen since you have to tap the main view in order for it to modally swap in the second view. If I interact with it everything works for a few seconds, then it closes with no crash log.
I finally realized that some of the objects must not be getting released fast enough, since if I close the app and wait three seconds, then reopen, everything executes fine.
I didn't want to put down code to show as this is more of a brainstorming question. I'd love any insight that could point me the right way. I changed a lot of my code to get rid of convenience methods and have all my variables defined and then released in my dealloc.
Is there a way to truly tell the app to kill everything on quit? It's not set to run in the background so this is a bit odd. Thanks for your help I'm still new to this and learning!
Alright, after working on this all weekend and doing more research comparing a barebones version of my app to my prerelease version, I traced memory leaks to the Flurry Analytics api that I am using. Apparently I was suffering from the same issue as the post here: App hangs on restart with latest Flurry SDK and ios4 . I resolved this by setting these optional methods to false, since they take extra time to send data after the app terminates, and depending on the connection it takes a few seconds.
FlurryAnalytics.h
/*
optional session settings that can be changed after start session
*/
+ (void)setSessionReportsOnCloseEnabled:(BOOL)sendSessionReportsOnClose; // default is YES
+ (void)setSessionReportsOnPauseEnabled:(BOOL)setSessionReportsOnPauseEnabled; // default is YES
Hope this helps anyone else who experienced something similar to me!
All apps can enter the background by default. Normally they do not do anything there, but they stay there in a frozen state and when you open them again, your program does not restart, it just picks up where it left off.
Anything that's set as an animation delegate might not get released, since it's retained for that purpose until the animation completes.
You can add an applicationDidEnterBackground: method to your app delegate to get informed when your app is going into the background, but exactly what you need to do depends on the design of your app. You can also add applicationWillEnterForeground: to do anything you need to do differently when restarting, as opposed to newly starting.
You might be able to force your animations to complete by starting a new animation with duration 0.0 (or very short if for some reason you can't do that).
If this happens only if your app goes to bkgnd and comes back AND you don't mind if the app restarts everytime it comes back then just put UIApplicationExitsOnSuspend in your app's plist. In all my cases where these and other bad things happen with apps going to and returning from bkgnd this helped.
While you might still see the app on the buttom when double tapping it is really stopped and will restart. Apps that show on the buttom do not always have to run or be stored in the bkgnd I learned.
ps. don't forget to set the value of UIApplicationExitsOnSuspend to YES
ok, like an idiot, in Interface Builder i started messing around with the connections and deleted a few connections (ie. delegates, controllers) and now when i build and run, all i get is a black screen. I know you cant see my code but could someone guess at what i would need to reinstate to get a working app back!
Thanks
First guess would be that the window outlet is not connected. Then I'd check all the other connections that should be there.
Oh, and use a source control management system, i.e. git. :-)
I've got an issue with my iphone App and i'm not sure if its an xcode project issue or a code issue (I'm leaning towards xcode project issue at the moment).
If I reset the iphone simulator and build and run my app it works fine. If I then do a build and debug again the app will crash straight away with no meaningful callstack. The app will continue to crash until I remove it and start again. I didn't previously have this issue which makes me think i've just changed some project setting recently by mistake.
Has anyone had this before or can anyone think or a reason for this issue?
Are you saving/retrieving state? Without any other details, that's the first area I'd look into. Also try setting breakpoints and debug to pinpoint the problem.
paul_sns is correct, try setting breakpoint on your AppDelegate class and step-over. Probably you're retreaving a state that is incorrect. You could also activate the debugging console (run the application in debug mode) to see where it crashes (the callstack).
OK I've finally got to the bottom of it. I had quite a lot of memory overwriting going on (a sizing issue with a 2d array) and this was why it wasn't giving me any useful information when it crashed. Thanks for all the help - am glad I stumbled upon the problem before I pulled all my hair out!
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.
Ok so I've got a really annoying bug in my app. It's driving me crazy and I'm sure it's beyond my skill level as I am learning as I go.
Here is the initial rundown of the bug: A shot in the dark - Application bug
However I have found a way to consistently reproduce the bug (only on the device not in the simulator)
First you create a new Pool and save it. Then add 20 blank time entires into one day. Save it and this is where the problems begin. (when you go back to the main detail view the tableview has put itself out of editing mode with being told to do so). Now if you go back to the day to see the time entries you just added they are still there.
If you go back to the main overall tableview listing all pools and now go back to the day you added the times they have dissapeared.
Add one time and it all saves fine. Add twenty and it doesn't save. WTF!!
Main Menu listing Pools:
Detail view:
Edit View:
Time Edit View:
Add a time:
I'd appreciate any more guesses. But as well as this question I'm offering a bounty of £25 (Sorry I'm a poor student) to whoever is good enough to fix this bug first!
if your interested my email is danmorgz[at]gmail.com
Thanks,
Dan
If you haven't already done so, I'd recommend turning on NSZombie support and seeing if you're using any of your objects after they've been freed. As far as I know this can be turned on in the simulator and on the device.
Most likely, you're failing to retain some object somewhere along the way. When an object gets released and then the memory is re-used for something else, you'll get all sorts of bad behavior, including crashes, or mysterious "disappearance" of other objects.
One thing you can try is putting breakpoints into the -dealloc method of your custom classes. Then you can see where they're getting deallocated from. Most likely though, this will end up being when the AutoreleasePool gets drained, which won't tell you much.
Alternatively, look into using some of the memory debugging tools built into Cocoa.
That document is for Mac OS X, but I think most all of this will work in the iPhone simulator, at least. I know that your bug "doesn't happen" in the simulator, but that really only means that the symptoms are different, and you're not noticing them.
Thanks for all your answers. It's now fixed.
For those interested I'd forgotten to add a cellidentifer in the XIB of my cell subclass.
cellForRow: method was therefore creating a new cell every time. The memory got filled up very quick. It then seemed as though my app was automatically trying to cut the fat by forcing another tableView out of editing mode and not managing my instances properly.
Again it's a memory problem. Isn't this always the case!?!
The clue was a one off 101 error in the console indicating my app was using too much memory. Oh and a slow scrolling tableView.