I have an iPhone app, that seems to have memory leaking problem. It's a puzzle game, after a few puzzles, the app crashes on devices.
I'm now trying to use xcode Instruments to detect what's going on. First time to use Instruments.
I noticed a leak bar in the "Leaks" plot, right the time when the view is loaded:
What are these memory leaking objects, detected by xCode Instruments?
. However these leaked objects are small, so I guess my app has other problems.
When my app continues to run, usually for 10+ rounds on an iPad 2, it then crashes. I don't much about Instruments yet, so I watch "All Heap Allocations". At the beginning of first round puzzle, the column "# Overall" is ~70k, it grows slowly between rounds of puzzles. When a new round puzzle comes in, it goes to ~90k, then round by round it reaches ~200k, then crashes.
Before crashes, in the log console I see memory warning and "CONNECTION INTERRUPTED".
I've followed a few things after searching memory leaking, such set NSArray/NSDictionary or mutable ones to nil, as much as possible (although not all of them, since some go between puzzles). I also changed UIImage imageNamed to [UIIMage alloc] initWithContentOfFile.
What else should I look/check to see what causes memory problem? TIA!
EDIT:
I wish I could post some codes that may be the suspect, but I really don't know what part to post. I should've check via Instruments in the course developing, so that I would know what caused the problem.
Regarding other view controllers. I do have others (menu, settings, app-store-rate, etc) and I generated all of them via code. My app doesn't have a storyboard or nib file. When I test crashes, I just click Next Puzzle button, so all other views will not show at all. So, before crash, the only view shown is the main view, with a few button, a few subviews, an animated pictures (but only the first puzzle as introduction). If it helps, here is my app:
http://itunes.apple.com/us/app/wordsect/id599455449?ls=1&mt=8
If you trying to debug application with Instruments - enable zombie detection mode:
In
Xcode: Product->Scheme->Edit Scheme
Select Debug scheme
Select Arguments tab bar on the scheme description
In Environments variables add and check NSZombieEnabled variable
Then when you start application under Instruments control, you'll get name of the instance, when your application crashed.
Related
We've got an app that's fairly large now, and we recently upgraded to iOS 10. In doing so, a new bug was introduced, and we're at a loss for how to solve it.
The crash itself occurs during a call to layoutIfNeeded(). However, the crash does not occur unless the layoutIfNeeded() call is contained inside a UIView.animateWithDuration() block. No amount of weak referencing, delays, or dispatch calls seems to have any effect. The same crash can be triggered during a call to [super viewWillTransitionToSizeWithTransitionCoordinator].
"An Objective-C message was sent to a deallocated 'Bubble' object (zombie) at address: 0x10924f030."
Enabling Zombies shows that we have a Release call going to one of our UIView subclasses, which we've named Bubble. Nothing too special there, some layout constraints and a gesture recognizer.
The Instruments app hasn't helped much, nor has the new visual memory debugger in Xcode 8 (though it is awesome, surprisingly little documentation on the feature).
I've included a screenshot of Zombies during the crash here. While I know the retain count can be misleading, there are certainly some confusing points to the trace, and we could really use some help diagnosing this.
Again, this code worked fine before iOS 10. We've been unable to find any notes from Apple about underlying changes to UIKit that may have had an effect.
Some more brief info: [Bubble cleanBubbles] simply iterates over the subviews of any view passed in, and removes the subview if its a Bubble class.
Apologies on certain violations of naming conventions, I'm sure there's plenty to criticize!
Thanks
I've got a TableViewController with static table; one of it's cells houses an UIView named graphArea. The view renders a chart, it's background and an axis line - all inside it's drawRect(). There are also two another views (sunView & markerView), that are made with Interface Builder and used for chart dynamics (moving marker line and point on touch events).
All worked buttery smooth until I've implemented and tried to test a share button, that employs the ordinary activityViewController mechanism.
The magic begins, when one from a couple of share activities, whose share plugin window takes the full screen, is finished (no matter whether sharing succeeded or cancelled). The app crashes.
Discovery using debugger made apparent to me, that the crash happens, because some views, including graphArea, sunView, markerView are nil after return from sharing screen.
Only some of fullscreen share plugins (like preinstalled Mail and Messages, or, in my case, "Download to DropBox" action) lead app to crash. Other fullscreen share plugins do not (tested Telegram, WhatsApp, Skype). No one of those non-fullscreen plugins has ever caused crash (Evernote, Twitter, 2Do etc.).
It looks like graphArea, sunView, markerView are deallocated from memory when "malicious" share plugins take full screen. I haven't figured out, why.
Here's some debug info:
The traceback and assembly of fatalErrorMessage.
The next screenshot shows a part of controller code and properties, that are nil on return from share plugin (gray selection). And yes, they were all non-nil before.
Please, help me! Thank you in advance!
Thank you, Palpatim. My friend also pointed me at the same thing: I've put graphArea.removeFromSuperview() in viewDidDisappear(), and this caused the exception after share plugins, that have .presentationStyle = fullScreen. So at the point, when the app is to show again, there is no more graphArea in on the tableView.
I have an iOS(7.1) app which crashes due to EXC_BAD_ACCESS. If I am not wrong, this happens due to the use of an object which is already de-allocated. After a bit of searching, I found out that enabling Zombie objects help to pin point the line of error. As I am using xcode 5.1.1, I have done the following to Enable Zombie Objects.
And then, checking the Enable Zombie Objects checkbox,
Then I went to Instruments panel, selected Zombies,clicked Profile and got this,
Now the simulator (in the left background), which had a button and a textfield is running blank and also I can't understand anything on the Instruments panel.
What should be the next step? I mean how can I get the lines which are causing the bad access? I am stuck on this for hours but still couldn't find the procedure.
Any help is appreciated.
Accessing a deallocated object is not the only reason you would get EXC_BAD_ACCESS. Other causes of bad access errors include accessing nil pointers and going past the bounds of an array.
Looking at your screenshots, you are not using a deallocated object. If you were using a deallocated object, the Zombies template in Instruments would let you know. Instruments would show a message similar to the following:
Your next step should be to set an exception breakpoint in Xcode. When your app crashes, Xcode will pause your app at the point where the crash occurs. To set an exception breakpoint, open the breakpoint navigator by choosing View > Navigators > Show Breakpoint Navigator. Click the + button at the bottom of the navigator and choose Add Exception Breakpoint.
I am creating an app with an UIViewController which displays other UIViewControllers with the MPFlipTransition inside it. It's like a little book on iPad.
The UIViewControllers inside are created each with xibs with 4-5 UIImageViews inside and some of those images are animated with CoreAnimations ([UIView animateWithDuration] blocks)
I remove all the animations in the viewDidDiseappear function with the QuartzCore function removeAllAnimation on each animated layer.
But when I'm testing the app on an iPad 3, it works properly, but on iPad 2 it crashes at about the 8th page change.
I've made a profiling with Instruments and found that the real memory usage was increasing everytime I turned the page (when the MPFlipTransition appears). But even if I remove from the superview the previous views, the real memory usage is not decreasing. I thinks that it created the crash on the iPad 2 because the crash come when the real memory usage is passing the 400 Mbytes value (and the iPad 2 has only 512MB...).
What do you think about this problem ? Any help ? I'm using ARC for memory management...
Thanks for you help ! Feel free to ask if any need of precisions...
i'm currently working on an ios project with some people, one of us decided to use ARC in a part of the app.
Unfotunatly, we are currently experiencing some crashes when coming back from background.
Here are the steps we follow to crash the application, we perform them with the ios-simulator:
start the application
get on a ViewController A (coded with ARC)
get on a ViewController B (not coded with ARC -to be honest i don't
know if it's relevant-)
put the application in background.
simulate a memory warning (thx to the simulator)
start again the application, we'll be on the ViewController B
go back on the Viewcontroller A
the application crashes pointing the main function with an
EXC_BAD_ACCESS
We did try to use NSZombieEnabled to YES, but when we do it, the application doesn't crash and keeps running perfectly, so we wonder if it might be possible that NSZombieEnabled doesn't work well with ARC?
if anyone could give me a quick and clear insight about ARC and NSZombieEnabled that would be apreciated, i think i know how all of it works, but apparently i must be missing something.
Thanks anyway for your help and time.
Better than using the NSZombieEnabled, you should Profile the project, and use the Zombie instrument. When you do the same thing it should stop and say "zombie messaged", where you can click an arrow to see the class that is a zombie, and where it was allocated/deallocated.
I don't think the crash has to do with ARC, instead in viewDidUnload you are deallocating something, and then not setting a reference to nil - when you come back it tries to use the invalid reference.
Probably you would be better off if everything used ARC as it really helps to cure issues like this (the bug is very likely in the non-ARC code).