I have two Levels level1.mm and level2.mm
In Level1.mm i use button named "skip level" MenuItem to Replacescene to go to level2.mm ,But when that method gets called, my app crashes with exec bad access.
But if i use PushScene its going to level2 scenes properly.But I know somewhere memory will be waste if i use pushscene.
What is the bestway to replace scene?should i call any dealloc before replacescene or it will be called automatically?
note : Please Be gentle this is my first game in iphone :) :)
The fact that replaceScene crashes but pushScene does not tells me that the first scene has some kind of issue when it is being deallocated. So your question isn't about how to replace scenes, but rather how to find and fix the bug that causes the crash.
Try this tutorial to learn more about debugging with Xcode. And since you're new, you probably aren't using ARC yet. Do that now because it'll help to avoid a ton of similar issues.
Related
I am trying to access the UITextView delegates and have a problem
I have a UIViewController with the UITextViewDelegate protocol and a Nib containing the textView.
If I set the delegate inside viewDidLoad like "textView.delegate = self" and I touch the textView, the app crashes without logging errors.
If I start editing the textView with code like "[textView becomeFirstResponder]" all delegates get called.
When I set the delegate in the Nib creating a connection between the textView and the File's owner and deleting "textView.delegate = self" also no delegates get called.
What am I doing wrong here?
Regards,
Elias
It's not easy to help you without more description, posted code or a xib file.
You say application crashes without any logging errors - well, do you mean that there's no output in console's window ? That is normal, for an app that has crashed.
Anyway, you should be able to get the stack-trace to figure out where approximately the application has crashed. Open the debugger (⇧⌘Y), and see the position. That should give you an idea of what went wrong.
Here you can see an example of such debugger session (after EXC_BAD_CRASH):
First two lines doesn't give us much information, but later on we can see that application has crashed while loading user interface from a NIB file. Well, usually the only code that executes during such load are awakeFromNib methods - it's up to you to find a problem along those lines.
Often top of code's execution doesn't make any sense - for example you might see your ViewController method somewhere, but the top few function calls (those where the code crashed) are located in methods/classes which you never call in your code. In most cases that is a sign of wrong memory de-/allocation. What might happened is that you forgot to retain some of your objects, it has already been released, but you are still keeping reference (a pointer) to its memory. Because that memory has been in fact freed, another object took its place later on, usually some Apple's internal object you've never heard about. Later on your code tries to message your poor object but it sends a message to something completely different. BUMMER! That's how you get those crashes and strange stack traces.
To fix the kind of problem I've just described you can use Instruments and its Zombies instrument. Unfortunately you can't start Zombies from within Xcode, you need to start Instruments standalone, then choose the Zombies under iPhone Simulator/Memory, then Choose Target from the toolbar, you should see your application in there, or be able to navigate to it on filesystem.
What Zombies instrument does is that it never really frees memory after objects are deallocated. Instead, it will mutate those objects into NSZombie class. That class intercepts all calls to itself, and informs you when some code is trying to send a message to it.
This is how such Instruments session looks like (this is the same crash as seen in debugger above):
In the table you can see that we're trying to message UIScrollView that has already been deallocated. You can as well see the whole history of retain/release calls to this particular object. That way you can find a missing retain or wrong release/autorelease.
Remember - Zombies Instruments can only be used with Simulator, because there's not enough memory on the real device to keep all those memory blocks.
Hopefully I could help you with further analysis of your problem.
I have created a music application in iphone .
The App crashes if i keep on switching between the tabs while the song is playing.
How can i solve this problem .Please anybody help me regarding this problem
Generally such kind of issues are memory related.......just check whether ur releasing the objects at proper place or not..
Other u can put some code snippet to have a look so that we can know actually what's happening with your code..
A common cause for crashes when something repetitive happens (eg switching between tabs, screens etc) is memory problems. Make sure you are releasing the correct objects in the right place. It could very well be that every switch you are allocating objects - without freeing them when switching again. This will eventually consume your memory and crash the application.
So I'm getting a EXC_BAD_ACCESS error in cocos2d. From what I've been searching so far it's mostly related to attempting to free an object which has already been released. I have encountered this error before, and its solution was simple and pretty much caused by freeing a released object. But now, using cocos2d (not sure if it's a bug in their framework or not), I'm getting an EXC_BAD_ACCESS in this line:
CCMenuItemSprite *btn = [CCMenuItemSprite itemFromNormalSprite:op selectedSprite:op target:self selector:NSSelectorFromString([sceneMethods objectAtIndex:i])];
Basically, I'm creating a simple menu system for easy maintenance and updating. Nothing too serious. In this particular line, I'm creating a CCMenuItemSprite with self as target and using a selector. I've already asserted that the selector passed as argument is correct and also tried to use different for the normal and selected sprite (though that shouldn't make any difference) but still no go! The error is deep in the cocos2d framework, precisely when the CCMenuItem is "activated" which calls invoke on a NSInvoker of that same class. And analyzing the stack trace, it crashes exactly on the invoke method, which leads to believe it has something to do with the NSInvoker. Anyone had a similar problem or have a suggestion for this problem? Thanks in advance.
Just a guess: are you completely sure that all of the objects in sceneMethods are real selectors?
I'm trying to use XCode's Leaks utility to fix some memory leaks in my code. Is there a better and more understandable way to check for leaks with explanations that pinpoint the exact line and/or offer suggestions?
Another question, I'm using AVAudioRecorder in my code in one of my view controllers. Should I load the recorder in viewDidLoad or in viewWillAppear?
If you're using Snow Leopard, have you tried using the static analyzer?
As mentioned, use Static Analyzer as a first line of defense.
It will not find everything.
But here's the problem with what you are requesting of Leaks. Think about what a leak is - a leak is when you have memory, that should have been released, but it is not.
So that means you are MISSING a line of code, that could have been placed anywhere - doing the actual release at the right time. But how could the tool possibly know when something SHOULD have been released?
So instead, the tool does the next best thing. It tells you where the leaking memory was allocated, then from there it's up to you to figure out where the object travelled and when it should actually have been released.
Static Analyzer will find the cases where you should have released in a few lines of code from when you created the object. Anything else, you just need to use Leaks to get a starting point to track down when you need to release something elsewhere.
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.