When I debug a project or when a project broke down, the Xcode console often put out some information about objects' memory address.Is there any way to figure out which instance the address is referring to and to locate related code lines?
Add a break point for all exceptions. That should do what you might really want in most cases:
Related
I have recently updated to macOS 13.0 and for that minimum XCode Version required is 14.x series. But my existing project never getting successfully building. Its getting stuck at some point.
Its not getting failed. Build process screenshot is attached below. Its not pointing to any specific class. Seems like there are lots of classes which are getting compiled successfully at last but still build process is stuck at some point:
Seen similar threads like below on apple pages but nothing seems working. Does anyone got resolution?
Xcode 14 project compile error
XCode 14 compile errors immediately disappear or do not appear at all
Something similar has happened to me in the past on a number of occasions. If the Swift compiler is hanging mid-build, usually the issue is that there is some expression that is too complex for Swift to do the type inference on.
What you need to do is first find the exact statement that is causing the hang. This is how I do it:
First find out which source file is causing the problem. Look at the build log to figure this out (the build log can be located by looking at the reports navigator ⌘9 ). Find the build log and click on it. The build log will appear in an editor window.
One of the compiles will still be in progress and its file is the one you want.
The next thing to do is comment out all the code and recompile. This time the compilation will finish (if you have the right file, or there is only one) but probably with a lot of errors. Then you add the code back in, function by function, until one of them causes the compilation to hang again. If it's not obvious which line of the function is causing the problem, comment it out again and then add the lines back one by one until the compilation breaks again.
Once you have located the line, you need to simplify the type inference on that line. If it's a closure, try adding an explicit declaration for its parameters and return type. If it involves some complex array, try adding a type annotation to its declaration. Also try breaking down complex expressions into multiple simpler expressions.
There's no one size fits all answer to this but usually, once you have located the exact line that is causing the problem, it should be reasonably obvious how to fix it.
I'm migrating my project from AudioKit 4 to AudioKit 5 and currently stuck on a bad access error. The variables look like they are passed correctly into the SynthVoiceStart method. I'm quite stumped why it's throwing the error as it should be a simple change from AKOScillatorBank to the Synth object.
The project code is accessible HERE on GitHub.
I've attached a screenshot below.
XCode Error
Thank you, a simple mistake on my part.
let engine = AudioEngine()
Was accidentally inside the 'init' method and was not declared beforehand. This meant that AudioKit did not start correctly.
The corrected code is below.
XCode Correct Structure
This is more of a comment, but I don't have enough reputation.
In the past I've investigated and managed to solve EXC_BAD_ACCESS errors with AudioKit by using Address Sanitizer (ASan). In XCode go to Edit Scheme, Diagnostics tab, and tick the Address Sanitizer option. When your program is recompiled and run, ASan will print a report whenever a memory error occurs. This sometimes gives useful information to resolve the error.
I've searched around and can't find anything on this.
Using Swift 2 and Xcode Version 7.0.1 (7A1001). Every time I execute something in the debugger console, Xcode crashes.
The project is not very big, and has less than 10 third party frameworks.
I can't think of much more information that's relevant, but I'm sure there's more, so please do ask me if there's anything I should add to my question that would help.
I've of course cleaned build and derived data.
It's driving me insane. Thanks!
UPDATE 16/11/12
Submitted rdar://23559366.
How are you maintaining your third party frameworks? Via Carthage?
If so then this is probably your issue: https://github.com/Carthage/Carthage/issues/924
This is an issue if the location of the /Carthage/Build/iOS folder is in a different location to where it was produced (i.e if it was compiled on a different machine and the absolute file path has changed).
A temporary fix would be to run carthage build --no-use-binaries on your machine to rebuild the symbols using the current absolute file path working around the bug.
But if you wasn't using carthage then its probably not your issue so sorry
I had similar problem with Xcode whenever I hit breakpoint.
In case you see this screen right before your Xcode crashes - you are lucky and my fix might save you. All you need to do is open this window and in the Project Navigator, select any file that you want, so that instead of that white blank view you would get your code. After this you are most likely will be able to successfully stop your app at your breakpoint and perform the debug.
I am not sure why this happens, but I suspect that the reason is Debug View Hierarchy mode, which you might have triggered prior to setting you breakpoint and trying to stop at it. At least this is when it happens to me.
I have similar problem earlier.
If you try to print non-optional variable and unfortunately it holds nil value then it breaks/crash. so that make sure declare all possible variables as "Optional type".
It used to work fine but now I get this message when loading a certain scene and then the APP crashes.
2012-12-01 18:33:55.104 AppName[9561:707] cocos2d: CCSpriteFrameCache: Trying to use file 'art1-hd.png' as texture
I have no idea on where to start debugging this. Is there a way to get a more precise error message to understand why this happens?
Btw, I have changed my code signing identity to developer and XCode doesn't yet give me any trace of it on the console other than the plain message above. I checked as well the device logs on the Xcode-Organizer section but no trace.
I whish there was something like in Java + Eclipse, where I could get a precise STACKTRACE of where the crash happened.
Any suggestion on how to get a precise stacktrace (E.g. with function name generating the crash)?
PS: I have set strip debug symbols to "NO" in DEBUG, and to "YES" in Release, but I am builing on my own test iPod and hence I think it is automatically build for "Debug" (the section says build for running and testing which is confusing as the project settings allows only debug and release). But I think the problem is not here.. but in the issues above before the PS:
EDIT: If I look into the debug navigator I don't see any stacktrace of methods, as I want, but just threads.. I need to figure out how to use the global exceptions.
I have no idea on where to start debugging this.
You have the cocos2d source code. I would start there.
Search for "trying to use file" in CCSpriteFrameCache to understand what the cause of this message is (which I agree is confusing, why shouldn't you use that file?).
As for the stack trace, it's available as soon as you add a global exception breakpoint. If the breakpoint triggers in OpenAL code make sure to set it to catch only Objective-C exceptions.
I need to debug the startup for an ios application on an actual device... and by start up I mean the very first instruction that is is executed when the OS hands control over to the app. Not "main". Also, this application doesn't have any symbols (ie. the debug information isn't available.. yet). I don't care if I have to debug at the CPU instruction level. I know how to do that (done it for over 30 years). I want the debugger to stop when control is about to transfer to the app. When I use the Attach|by Name command and run, it just says "Finished running".
Oh, and this application was not built in XCode. It is, however an application I built, signed and provisioned and moved to the device. The application does run since I can see the console output. Just in case you're thinking I'm some hacker trying to debug someone's application.
How's that for a tall order? I'll bet nobody can answer this... I've not been able to find any information on how I could do this with an XCode-built project. I wonder if it is simply not possible or "allowed" by the Apple overlords?
What do you say, Stack Overflow gods?
UPDATE: I should clarify something. This application is not built with any commercially available or open-source tool. I work with a tools vendor creating compilers, frameworks, and IDEs. IOW, you cannot get this tool... yet. In the process of bootstrapping a new tool chain, one regularly must resort to some very low-level raw debugging. Especially if there are bugs in the code generated by the tools.
I'm going to answer my own question because I think I've stumbled upon a solution. If anyone has anything more elegant and simple than this, please answer as well. On to the steps:
Starting with a raw monolithic iOS executable (not a bundled .app, but the actual binary mach-o file that is the machine code).
Create a new like-named empty Xcode project. Build and run it on the device.
Locate the output bundle's .app folder.
Copy the above raw iOS executable over the existing one in the .app bundle's folder.
The application will now have an invalid signature and cannot be deployed and run.
Run codesign against the app bundle (you can find out the command-line by running xcodebuild on the above Xcode project).
In the bundle's .app folder, run otool -h -l on the binary image. Locate the LC_UNIXTHREAD load command and find the value associated with the 'pc' register. This is address where the os loader will jump to your application. If this address is odd, then these are Thumb instructions otherwise it will be ARM (I think that's how it works).
Add a symbolic breakpoint (I used GDB instead of LLDB) and enter the address as '*0x00001234' as the symbol.
Select Product|Perform Action|Run Without Building.
Assuming that GDB is able to evaluate the breakpoint expression and set the break point, and you've selected Product|Debug Workflow|Show Disassembly When Debugging, the process should break at the very first instruction to be executed in the application.
You can now single step the instructions and use the GDB console to get/set register values.
Your question does not make sense - main is the entry point into the application. It is the first code that should be encountered, unless possibly you have initialize() overridden for some classes (but even then I think main would get hit before the runtime).
I think you are seeing some kind of odd error on launch and you think you want to set a breakpoint on entry to catch it, but far more likely what would help you is to describe the problem on launch and let one of the 4000 people who have seen and fixed the same crash help you...
However, if you really want to use GDB to break on an application with no symbols (but that you launch from XCode) you can have GDB break on an assembly address as per:
How to break on assembly instruction at a given address in gdb?
To find the address of main (or other methods) you can use tool or atos, some examples in this question:
Matching up offsets in iOS crash dump to disassembled binary
ADDITION:
If for some reason XCode cannot launch your application for debugging, you could also jailbreak and install GDB on the device itself which would give complete control over debugging. If XCode can launch you application I see no reason why being able to break at an arbitrary memory address does not give you the ability you seek...
One solution for applications with webviews is to run them in the iOS Simulator, and connect to that with the remote-debugger in macOS Safari. This is off-topic but maybe the one or other could benefit.
http://hiediutley.com/2011/11/22/debugging-ios-apps-using-safari-web-inspector/
Or use NetCat for iOS... not the most perfect solution, but at least you see what's going on.