The app I am developing has a weird issue since a few months. Sometimes during building an archive the error cdtool cannot compile occurs. But only sometimes.
When I wipe the derived-data and do a clean-archive it works again.
I found a variety of people asking similar questions, but they all had this error occur nonstop.
To be precise: The error occurs always during archiving and always on the same file which is Config.xcdatamodel. This CoreData model only has one version so version-conflicts aren't a problem (also verified on the file-system).
Unfortunately it is nearly not reproducable at all, it seems to occur 100% randomly. It also doesn't provide an closer information about what exactly it is, that fails.
In the image there are two compile-errors. Thats because the Config.xcdatamodel that fails, is in both targets. They won't be used at the same time, so it should be fine. I also suspect that the second error-message is based on the first (upper) one.
Did anyone ever observe such a behaviour? I'm currently using XCode 7.2.1
My code is unable to build on xcode 7. What is Segmentation fault?
A segmentation fault happens when your code tries to access memory that it isn't allowed to access. This is often a sign of an uninitialized reference.
It's not clear to me from your screenshot exactly what is going on, though. Perhaps you could provide more details?
From the screenshot it looks like it is happening when you build your project. If this is correct, you need to create a minimal example that displays the problem i.e a code fragment that crashes the compiler in the same way and then you need to raise a bug report about it with Apple (supplying your minimal example so they can reproduce it).
This has happened to me a couple of times in the past and the way I have identified the bit that crashes the compiler is to comment out everything in the source file and then add it back in function by function.That will narrow the problem down to the function. After that you repeat with the lines of code in the offending function, until you get the line that crashes the compiler.
Along the way you may find a work around to stop the compiler crashing. If you do, do not be tempted to skip reporting the bug to Apple. They need to know.
Why do I have this following break point be triggered every time when I launch my application?
I added "All Exceptions" break point in my project, but I don't know what kind of exception is this. The app can keep running if I skip this break, however when running in the device, there's a crash happened couple times due to the same call stack.
Your crash is occurring during global / static initialisation. You've probably got some unsafe code tied to the initialisation of a global variable, but it's hard to say without more context.
If you're seeing this crash on iOS9 (beta 3), it may e related to one of the libraries you're using. If you're using Cocoapods, try to remove them one by one, until you find the responsible one.
In my case, the crash was caused by the ArcGIS SDK: https://github.com/bamse16/TestEsriiOS9
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.
My app was crashing only when not running using XCode debugger. It was hard to track because I can't debug but I finally figured it out. It was because of calling release on some object not owned by me. Before I corrected it I searched and found 2 related questions here (links below)
iOS App Crashes when running by itself on device, does not crash when running through Xcode using debugger, or in simulator
iPhone crash only when device not connected to xcode, how to understand the crash log?
None of the above question has answered why no crash when running via debugger.So my question is why it happens ? I know reasons for debug/release specific crashes but this is crazy. Is it just by chance although it happened more than 10 times.
What you describe is not atypical of obscure memory-related bugs. You might also want to use debug-malloc at such times. Although that is not guaranteed to find everything. The reason (and it's been happening probably as long as there've been source-level debuggers) is that memory is laid out at least somewhat differently in debuggable code, and when running under the debugger. So the error results in a different piece of memory being (harmlessly) corrupted when under the debugger. When not under the debugger the location corrupted is actually something that your code cares about, and it crashes.
The same could happen in reverse, but you'd never know - if it crashes when run debuggable, you'd find it before switching to running outside the debugging environment.
Reiterating #jyoung's answer since I didn't see it the first time I glanced through:
Try running with Zombie Objects turned off.
In debug mode if you have it turned on it is handling memory allocation differently. Try running it without.
Go to Edit Scheme... > Run > Diagnostics. Then make sure zombie objects is turned off:
Then run through your code path again.
I had this same issue while working on a project modularised with Xcode Frameworks. Even after removing all the logic in AppDelegate and only returning true inside application:didFinishLaunchingWithOptions, I was still getting the crash. Then I switched to my project settings, in the Frameworks, Libraries, and Embedded Content section and changed the embed option for the frameworks I added to Embed & Sign. This was what fixed the issue for me. I hope someone finds this helpful.
I was having this problem as well and was fortunate to figure out the cause quickly, hopefully by posting here I can save someone else some wasted time. To clarify, my app would run with no issues when launched directly from XCode, but would crash immediately when launched manually on the iPad.
The app in question is written in Obj-C but relies on some 3rd party code written in Swift. The Swift code is included in the app as an embedded framework. I had to set "Embedded Content Contains Swift Code" to Yes in the Build Settings for the app (under Build Options), then the problem went away.
I experienced this symptom when I made a NSString, sent a UTF8String from it to another object, and assigned it to a char pointer. Well, it turns out that I forgot to retain the original NSString, which wouldn't have mattered anyway, since I also failed to realize that the UTF8String method (which is presumably an object that gives access to the pointer itself) operates in the autorelease pool. That is, retaining the NSString itself did not fix the problem.
I suppose this appeared to work just fine when attached under the debugger only because I had zombies enabled, so the pointer I had was still valid. I should see if this is the reason it worked; if so, this is a good reason to test with and without NSZombie enabled.
At any rate, this was probably poor design to begin with, and a pretty obvious newbie memory management mistake once I found it. Luckily the console in the Organizer window gave me some hints on where to start looking, and debugging ultimately showed me where my pointer's value was changing. Hope this helps anyone who finds the way here.
I had this issue when accessing SQLite databases from outside the [[NSBundle mainBundle] resourcePath] directory, which caused iCloud errors.
I discovered the error only by installing a Console app onto my iPhone which logged the errors.
Once I accessed the databases from the correct directory, the errors disappeared and the application booted correctly.