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
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.
NOTE:
It has been a few days and I still am having this problem. One thing that would be helpful, is to know some troubleshooting ideas to try, so I can track down what is causing the crash. Any help that would lead me in the correct direction would be greatly appreciated.
I'm running in Xcode 8.2.1 on the simulator, as well as on several different iOS devices. I get the same problem wherever I go.
I have imported a small mp3 file into my spritekit project, called "cat_meow_1.mp3"
when I select the file, in Xcode, and hit the play button, it plays normally. Incidentally I have tried with various different files in various formats, with the same results.
in my code, which complies okay, when I get to the line:
run(SKAction.playSoundFileNamed("cat_meow_1.mp3", waitForCompletion: true))
I get a crash with the error message,
error: use of undeclared identifier '$r0'
Any suggestions how to debug this problem, or to figure out what I did wrong?
I also tried to preload the sound and make a class property, but got the same error. Here's what it looks like:
UPDATE:
After reinstalling Xcode, I still have the same problem. With certain files, I get white noise, while with other ones I get the error here. What else could be wrong with my system to cause this problem?
UPDATE 2:
tried my experiment on a separate mac, and basically it worked just fine. I reinstalled my OS, and got the same problem, with a little more of an error message this time, which reads:
2017-01-18 18:10:09.397565 sound attempt 2[533:124220] [DYMTLInitPlatform] platform initialization successful
2017-01-18 18:10:11.058506 sound attempt 2[533:124042] Metal GPU Frame Capture Enabled
2017-01-18 18:10:11.059146 sound attempt 2[533:124042] Metal API Validation Enabled
error: use of undeclared identifier '$r0'
warning: could not load any Objective-C class information. This will significantly reduce the quality of type information available.
After a couple days, I finally gave in and used Clean My Mac 3 to completely remove Xcode, as well as any and all related files... I must not have caught everything when previously I uninstalled/reinstalled it, because this time, there were none of my custom settings at all when I ran the reinstalled app.
It works now, thankfully, and I can get back to work.
I am currently attempting to port a game I've developed in the Wintermute Lite engine to iOS platforms. My game will compile just fine in XCode (albeit using the armv6 architecture) and will run perfectly on the iOS simulator; however, when I try to deploy it to an iPad, the first thread will halt in XCode with the error "EXC_BAD_ACCESS (code=1, adress=0xfffffff6)", pointing to a non-specific line of assembly code.
First of all, if you guys have any ideas right off the bat as to what might be causing this, I would greatly appreciate some help. The thing is, I'm more than willing to debug this myself, but being a complete noob with Objective-C as well as XCode, I'm not sure how to trace this specific error back to the line of code that's causing it (I apologize if this is a really basic question but I've already attempted to find a command to get the line of code associated with the error, but with no success).
I realize that this is scant on details, but as I said, I'm not sure how to pinpoint the piece of code that's causing this error using XCode, otherwise I'd just debug this myself. If there's any extra information I can provide, let me know.
Thanks in advance for any help!
I got it working. After a lot of messing around with XCode, I realized that I incorrectly configured the project file provided by Wintermute. As far as I can tell, it had something to do with the fact that the project was originally set to build for "iOS Universal" and I changed it to "iPad 5.0," which somehow caused the project to break upon deployment.
Anyway, I started over with a new XCode project file and got it to compile perfectly! Sorry for the bother.
The problem is the fact that it isnt ment to run on iOS. The reason it runs on he simulator is that it is building for a Intel chip set, not ARM. Even though you set it to armv6 it doesn't mean that the code will run on a non-intel device.
I've been using RestKit in a project for the last couple of months without any issues. I have it set up as per the instructions on the Github wiki. Today Xcode hung while connecting to the simulator. I had just edited some trivial UI code completely unrelated to anything touching RestKit. I had to force quit Xcode and restart. When I restarted and compiled again, RestKit built successfully but I got a string of Errors related to my application. On closer inspection they are all related to RestKit. There are a cascade of errors starting in RKRequestSerializable then spreading out to every RestKit class that references it.
The first error is 'Expected a type' for the line:
#protocol RKRequestSerializable
then 'Expected selector for Objective-C method' for the line:
- (NSString*)HTTPHeaderValueForContentType;
then 'Expected a method body' for:
#optional
The first thing I did was revert the changes I had made since the last successful compile, but this made no difference. I then rolled RestKit back in case I had accidentally made a change, but this had no effect. I have tried deleting derived data, deleting and re-adding RestKit, but nothing has any effect. My project will not compile.
The strangest thing is that RestKit compiles successfully. The errors are from the compilation of my project. I've lost three hours on this so far and would greatly appreciate any input or suggestions as to how I might solve this.
Are you still building for the simulator? I've seen this behavior after an XCode crash. The Schema gets set to OS X 64 bit or something else and RestKit doesn't compile there.
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.