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.
Related
I have this map view with a bunch of overlays. When I hit the home button and re-open it, all the overlays disappear for a second and immediately re-appear. At first I thought it was my code that was doing it but I put breakpoints pretty much everywhere and none of my code seems to be triggering the "reset". Even mapView:viewForOverlay: doesn't get called before the overlays reappear.
I thought maybe this is an inevitable behavior of MKMapView, but it seems like Maps.app doesn't do it either — if you calculate a route and quit/re-open the app, the overlays stay there the whole time.
I'm thinking maybe MKMapView clears all of its annotations/overlays by default on quit so it takes less memory while staying backgrounded. Is there any way to avoid this? Kinda like Maps.app does?
EDIT: here's a small project I put together to demonstrate the problem. Just launch it in Simulator, click the home button, and re-open it. You'll see the map path overlay disappear for a moment.
This is more of a follow-up than an actual answer, but basically this issue has been flagged as a bug by Apple. I submitted this as a TSI to Apple a while ago and received the following answer:
Thanks for providing a sample project. I don't see any issues in your
code. At this point I recommend escalating the issue to engineering by
filing a bug about the "flicker" from the MKPolylineView being redrawn
at https://developer.apple.com/bugreporter/ and sending me the bug
number so I can use it to follow up.
I then submitted radar #11041378
Thanks again for your bug report. As it happens, I don't have a
workaround for you at this time. Engineering is still working on the
issue, but I don't have a timeline for a fix.
I'll go ahead and leave this incident open for you as long as bug
11041378 is open. If you have any questions about it's status in the future, or the status of a workaround, feel free to reply back and I
will check it for you.
If you have any comments for engineering, or want to tell the story of
why it's important to your situation, I'd actually encourage you to
put that directly in the bug. Since it's been assigned to engineering,
any comments will go directly to them.
I appended the following comment that describes why the issue is important to me:
This bug feels rather important to me as the user expects to find the
app in the exact state he left it when he quit the app. The flickering
overlays (sometimes disappearing for less than second, other times for
2-3s) may get the user confused about what is going on, when all he
really wants is to interact with the map/overlays right away.
Haven't heard back from Apple since. Hopefully this will get fixed in iOS 6?
I'm programming an application for iPhone. My application has a login system. In the login system (and somewhere around my app) I have some placeholder in the UITextFields.
After a couple of months working on this app, I noticed a sudden problem that arose once. If I don't write in the text fields that have placeholders nothing happens, if I write something in them, the blue bar that blinks showing where you are in the text becomes very slow. Moreover the ScrollViews that I have become EXTREMELY slow. Some other strange behavior happens when I have a wheel that lets the user pick some choice: the options of the wheel "fall" from the sky while the user rolls it.
All of this happens only if I write something in a UITextField that has some placeholder. If not, nothing of this happens.
I know this sounds REALLY strange, I used a MacOSX program to create a video of the text field becoming slow.
It's .swf.
try to do one thing.. delete this textfiled and create a new one with different name and see is this problem occurring again? also try to set breakpoints in your code and debug your code.
Are you sure you aren't leaking any memory or running an endless loop on the cpu? Try monitoring your app with Instruments and check your cpu activity and memory allocations.
I have an app that keeps crashing as soon as it starts. Not sure why. I have image views and buttons in the main xib file. The main xib file is not mainwindow, it is firstview, so i changed it in the plist to the firstview. There may be something wrong with the xib file for firstview but it only has buttons and images and a view in the back. There are no warnings or errors when I run it, just Debugging Terminated when it crashes.
To Debug a crash problem, especially on a small application, do a binary search on removing functionality and adding it back in until you find the smallest thing that when removed makes the crash go away, and when added back in causes the crash. Sometimes this bottom-up search approach is easier than the top-down analytical approach to finding what is the problem. Then when you know what is causing the problem, it's generally much easier to focus on why it is causing a problem.
What's the very last change you made before your app started crashing? That's the one that caused your problem. If you made a lot of changes at once before running your app to test them, now you know what that's a Very Bad Idea (tm)... :-(
You probably want to switch it back to mainWindow, and then add the view as a subview in the app delegate did finish launching. also, you may want to set a break point on obj_c_exception_throw.
I've built a Navigation-based app, but now that I'm knee-deep in the code, I've decided it would actually be best to have just a UIToolbar instead (only need modal views, not drill-downs). But extricating the Navigation stuff and replacing it with a Toolbar is causing me all sorts of grief...
Has anyone ever done this, and maybe has a pointer or two? Or even know of a walkthrough linked somewhere?
Thanks!
Bite the bullet and rewrite. Any guides out there will not be specific enough to your situation.
99 times out of a hundred if I realise I've made a massive design mistake and don't change it, I end up regretting it more than if I do. And since you'll take a copy/start from scratch again, you can always revert if you need to give up half way through!
Seriously, because this is a current app that is still (relatively) early in its development life and is all fresh in your mind it will very likely be quick to re-do. Also, sounds like this might be one of your first iPhone apps so you're likely learning new stuff every day - now you get to put all the new stuff in this app too. And finally, just imagine the work involved if you put another 200 hours into this as it is and then decided you had to rewrite!!
Hope that helps, and I bet you get it rewritten in less than a day!
I have an app that has a tabBar Controller and a navBar Controller. It has ~8 views (a variety of web, table, standard, mail, address etc.), some created using IB some created using XCode to make the table views. I've ran the memory leak tester and it doesn't have memory leaks. It can crash at anytime on any of the views, If I flip back and forth between views and use some of the functions it closes the app.
I assume that either I am running 1) out of memory or 2) not releasing views correctly, which causes the app to close. The app is simple so I don't know how I could be out of memory and I've reviewed the code to the best of my ability for releasing the objects correctly.
So Here is my list of questions:
1) What and How to use some of the other debugging tools (or tell me what tools/files I should be looking for using)? I would like to narrow down the problem to its source.
2) What is the best practice for releasing these views? How?
3) How much memory do normal apps use? Is there a number that I should stay around? How do I verify that in the simulator? the Allocation tool?
Feel free to point me to apple docs or other stackoverflow questions that can help me.
UPDATE: It appears to only be crashing one view is used, which has a table view with custom cells... The cell are populated from a plist file... this view worked fine a few days ago, I notice that some cells do not have data from the plist file... it could be a plist file problem with not storing proper data. I'll continue to work on it.
UPDATE #2: I went back to older rev of my files, to when this particular tableView worked just fine (pre 3.0) and guess what it works just fine, I change the simulator to 3.0 with this rev of the app and bam crash on this tableView shows up. Thanks for the help so far, I'll try somethings mentioned below and let you know what I find. If you have some tips on why a tableView w/custom cells from 2.2.1 to 3.0 would start crashing, I'll take them. If I can't get anywhere I'll post the code soon. BTW, I mis-spoke above, I thought it wasn't crashing in the simulator... I was wrong it is.
Solution: thanks for the troubleshooting tips the fix was quite simple, but it's odd it didn't crash in 2.2.1... it should have crashed a long time ago for the problem, I was releasing an object one to many times in my custom cell... duh.
On the first and second generation phone's you really don't want to be going over about 20 megs of real memory usage - once you get over that you are at risk of being killed by springboard.
One of the big culprits I've seen is autoreleased memory, since the autorelease pool can hold onto memory a lot longer than you would really like - if you are using a lot of autoreleased objects that can be a potential problem. You can improve this by doing more explicit retain/release where possible and by creating local autorelease pools manually and releasing them after doing a more intensive operation with a lot of autoreleased objects.
The most effective way to keep track of real memory usage I've found so far is running a debug build on a test phone and running with Activity Monitor. That will give you a clear idea of how much memory is getting taken and held onto by your app. As well as how much is being used when it crashes on you.
You can run with Activity Monitor in Xcode on the Run menu -> Start With Performance Tool -> Activity Monitor.
One other very useful tool is the CLang Static Analyzer that you can run against your code base and can give some very helpful memory management information. As mentioned here.
One thing I would try is putting some debug messages into your didReceiveMemoryWarning method(s). That way, if you are running out of memory, you'll at least have some warning.