I've been trying to tackle this crash and just don't know where to begin. Can someone help me figure out how to use Xcode's tools to navigate this information properly to find the culprit? I don't even know what these details are:
The Instruments tool should be your first port of call - particularly the leaks and allocations analyser.
To use it, select the Profile option off the Product menu in Xcode.
You might like to investigate using the NSZombie object which is designed to catch over-releasing of objects.
It may of course be that you're simply passing a pointer to something that is not a Core Foundation/Cocoa object where one is expected.
A good first step for xcode debugging is often setting an exception breakpoint. To do this select the exceptions tab in the left sidebar, and click the plus at the bottom and select Exception breakpoint. This can help because it will pause execution at the point any exception is thrown thus making it easier to track down.
That said, based on the screen shot you have posted, it looks like an object is getting released twice, so that might not help as much. Using log statements or additional breakpoints throughout the code might help you track down where the problem is occurring.
The details shown in the screenshot are the compiled assembly code, annotated with what is being called. CFRetain is used internally by cocoa to release objects (ie in the implementation of -release).
Related
I've not worked on this project in quite some time.. When I left it some time in the iOS 8s it ran just fine, however.. on the latest XCode I'm getting many inconsistent EXC_BAD_ACCESS crashes. Now afaik it's requiring a deallocated object. However, the error is lacking where to look. This is quite a big project and like I say, the errors are inconsistent.
I've tried enabling zombie objects, as well as passing it as a starting parameter. However, this is leading me to no joy. I'm expecting something in the debug console with zombies enabled, is this right?
If anyone has any tips on how to find an easier way to debug this, as opposed to tinkering with everything and hoping it works..
EXC_BAD_ACCESS just means that your app is trying to access an invalid memory address. While it is oft caused be a deallocated object, that isn't always the case.
When the app crashes, there should be a crash log or backtrace. Post it as that'll provide clues.
Lovely; a crash entirely in framework code. Seeing as how it is SceneKit that is crashing, I would suggest replacing any graphic assets with new ones and see if that fixes it (even if it doesn't look right). Then check to make sure all of your geometries and layouts are correct.
Have you tried adding a global Exception or Symbolic breakpoint? Those usually help me 99% of the time when I encounter issues without any sort of backtrace.
As soon as you hit "Play" what happens in the background of the software? The code is already compiled and ready at this point. So when I press "Play" the code gets executed. What other things occur along with this?
I have this question as an assignment and would really like to know. Thanks. :)
Actually everything is loaded by script. This graph explains the process. Also the links below can be useful for you to understand all the background process.
Execution Order of Event Functions
Overview: Script compilation
Asking what happens when you press Play is like asking Coke to reveal the drink recipe. This is what they sell. You got that as assignment, fact is you can say anything and your teacher would lie to tell you wrong, since he does not know either (except if he works for a company that bought the source code of the engine).
What you can say, is that the OpenGl/DirectX API is initialised, registration of all event to the OS like Input, application data and so on, then all the Engine functioning, registering of the needed classes in memory, init of the physics, parsing of the opening scene YAML file, creation of the content and placement in space, for each item, if a MonoBehaviour, registration of all callbacks, all the debug code related to profiler and stack tracing, crash reports and many more...
Those are the obvious ones and I cannot have any clue of what is going on without using a tool to decompose the code. Problem, it is against the EULA and then illegal.
I've got an app that gets information from a SOAP web service and I want to display the results in a UITableView.
I had a previous version of this app and I'm creating a new version to basically clean things up and get rid of a bunch of legacy code that's deprecated and no longer used.
In the previous version, this worked well. In the new version, not so much.
Basically, the current scenario is returning 3 strings that I'm trying to use as the basis for the data in my UITableView.
I'm struggling with this issue because it's so stinkin' hard to track down EXC_BAD_ACCESS errors!
(Parenthetically, if someone has a way to make the debug experience more like Visual Studio, I'd love to hear it! It's so frustrating to not have any idea which line caused the error, and also to not be able to look through my local variables at the time of the crash to see what's what. I've already added in the exception breakpoint, but that doesn't seem to do much.)
Anyway, the line that's causing the error APPEARS to be:
return [[self Libraries] count];
It occurs in tableView:numberOfRowsInSection:.
The error message I get APPEARS to reference a string that should be stored in the NSMutableArray [self Libraries].
What's going on here?
I'm using ARC, so shouldn't all of my memory management be correctly handled?
I don't have any manual release statements in my code ANYWHERE!
Please help me fix this!
Set NSZombieEnabled, MallocStackLogging, and guard malloc in the debugger. Then, when your App crashes, type this in the gdb console:
(gdb) info malloc-history 0x543216
Replace 0x543216 with the address of the object that caused the crash, and you will get a much more useful stack trace and it should help you pinpoint the exact line in your code that is causing the problem.
See this article for more detailed instructions.
ARC relies on the Apple standard/recommended naming practices. Check that you are not violating any of them.
Just for starters, if "Libraries" is an instance there are are naming issues.
OK, so I feel a little bit silly, but I've got two production machines. On one of them, I had installed a copy of Xcode 4.2 beta alongside the final, production copy. I forgot to uninstall the beta copy and was using it to run my code. As soon as I cleared that up and ran my code against the final, released Xcode 4.2, all works fine again.
As I mentioned to Jonathan Grynspan above, I DO understand Obj-C memory management. For some reason, I was getting a retain/release/release (performed by ARC), and that bug is remedied in the final version.
Thanks for the help in tracking this down! At least I got a definitive answer to WHY the problem existed!
Sometimes when looking at someone else's large Objective-C program, it is hard to know where to begin.
In such situations, I think it would be helpful to log every call to every non-Apple method.
Is there a way to do that? Basically, make one change in some central place, and log every method that is called. Preferably limited to non-Apple methods.
You can set the environment variable NSObjCMessageLoggingEnabled to YES. This will write a log of all message sends in the folder /tmp/msgSends-xxx.
You could add a symbolic breakpoint to objc_msgSend(), and have it log the second parameter without stopping.
How to do it for your own methods only though is a toucher task. Maybe if you could inspect the class name being called and do some magic to have a conditional breakpoint for only calls where the class' prefix matches your own?
I don't think logging every single call is practical enough to be useful, but here's a suggestion in that direction.
On a side note, if it's a large program, it better have some kind of documentation or an intro comment for people to get started with the code.
In any case, every Cocoa application has an applicationDidFinishLaunching... method. It's a good place to start from. Some apps also have their principal (or 'main window') class defined in the Info.plist file. Both these things might give you a hint as to what classes (specifically, view controllers) are the most prominent ones and what methods are likely to have long stack-traces while the program is running. Like a game-loop in a game engine, or some other frequently called method. By placing a breakpoint inside such a method and looking at the stack-trace in the debugger, you can get a general idea of what's going on.
If it's a UI-heavy app, looking at its NIB files and classes used in them may also help identify parts of app's functionality you might be looking for.
Another option is to fire up the Time Profiler instrument and check both Hide missing symbols and Hide system libraries checkboxes. This will give you not only a bird's eye view on the methods being called inside the program, but also will pin-point the most often called ones.
By interacting with your program with the Time Profiler recording on, you could also identify different parts of the program's functionality and correlate them with your actions pretty easily.
Instruments allows you to build your own "instruments", which are really just DTrace scripts in disguise. Use the menu option Instrument >> Build New Instrument and select options like which library you'd like to trace, what you'd like to record when you hit particular functions, etc. Go wild!
That's an interesting question. The answer would be more interesting if the solution supported multiple execution threads and there were some sort of call timeline that could report the activity over time (maybe especially with user events plotted in somehow).
I usually fire up the debugger, set a breakpoint at the main entry point (e.g. - applicationDidFinishLaunching:withOptions:) and walk it in the debugger.
On OSX, there are also some command-line tools (e.g. sample and heap) that can provide some insight.
It seems like some kind of integration with instruments could be really cool, but I am not aware of something that does exactly what you're wanting (and I want it now too after thinking about it).
If one were to log a thread number, and call address, and some frame details, it seems like the pieces would be there to plot the call timeline. The logic for figuring out the appropriate library (Apple-provided or third party) should exist in Apple's symbolicatecrash script.
I wrote an entire app, and I was just about to submit it to the app store, and in my final testing, I went back and added a few releases to ensure proper memory management was observed. And since then, I keep getting these random crashes. I've tried removing some or all of the release calls, I've tried retaining objects. I cleaned the project. I used NSZombieEnabled and that also is not helping. All this to not avail.
Most of the time, the console says provides no help. Usually the app loads, I put NSLogs in viewDidLoad, viewDidAppear, and viewWillAppear, and they all show up in the console, then it crashes.
Sometimes I also get EXC_BAD_ACCESS (and I know what that means). But its occurring randomly. So this doesn't make sense to me. Thanks for any help possible. I've written this whole app, and spent months on it. So I'm really stuck. Thank you.
Have you tried Build --> Analyze? It will search your code for leaks and other useful things you might have missed. Try that and see if it finds anything for you.
I agree with Rudy. It sounds like you're releasing something that is still in use. I would go back to the version that was working and start adding the releases one at a time til it causes the crash. Slow but effective debugging.
When you say that you "sometimes" get EXC_BAD_ACCESS, what do you get the rest of the time? Where does the crash stack indicate you're crashing? What messages do you get?
Random crashes usually indicate a timing problem. A common cause is accessing things on multiple threads. Are you? It can also mean timing differences based on network traffic.
Make sure the console doesn't indicate an exception rather than a memory violation. Usually there's something in the console that will be useful.