I've seen lots of people (including me) facing the crash with EXC_BAD_ACCESS with unknown reason. A lot of answers with the solution clean and build the project marked as correct.
I'm curious why this happens and how clean and re-build fixed it, but it seems people just don't care and go on with clean-build solution.
Here's an example of those EXC_BAD_ACCESS with clean-build solution.
In my case, I'm facing something as ridiculous as this:
func viewDidLoad() {
super.viewDidLoad()
self.childVC.delegate = self // => Crashed EXC_BAD_ACCESS here. Fixed after clean and build
}
As far as I know, this happened in Swift a lot more usually than Objective-C. Could it be Swift's features?
These are my thoughts:
Once run, if project is not already built then Xcode generates the required build files in:
~/Library/Developer/Xcode/DerivedData/
If the project is not cleaned, either manually or automatically, then the same build files are reused in running apps to reduce consequent build time.
You may have already noticed that Xcode sometimes automatically cleans the build after any major code change. For example, on:
changing static variables
changing objective-c code in the swift project
But Xcode still has it's flaws, and sometimes does not clean itself when needed making it possible to run with the, let's say, "broken" build files that eventually give rise to such EXC_BAD_ACCESS errors.
Cleaning it will clear the old build files and new builds don't have the same problem.
Related
In my project I need to generate a file that will be used in one of my Swift Packages.
I added a script to generate it as a pre-action to make sure it happens before anything else is build - and it works.
File is generated properly - it appears in Xcode project itself.
But Xcode doesn't pick it up when compiling this Package for the first time.
Next time I compile it - it catches it properly, but all further changes are not picked up again on first time it gets modified...
I found this thread with similar issue, but none of the solution works for me.
Doing it as a Step in Build Phases doesn't solve the problem, making it even worse.
Is there any reasonable solution to run some code generate that will be properly picked up by Xcode ?
Created a new question here with simpler example.
I have encountered some odd behavior from Xcode, including giving incorrect variable values and giving me syntax errors in older projects that compiled fine when I left them.
What is the best way of getting back to a clean Xcode?
Are there issues having two (or more) Xcode executables in the Applications directory? I am only running one version at a time...
Is it possible to completely remove all program data files and cache files, as if I've never installed Xcode?
If not, is there a list of caches/etc that can be safely deleted?
Here's what I've tried so far, based on Stack Overflow searches:
Clean project (CMD+OPT+K). Restart Xcode. Reboot Mac
Downloaded Xcode 9.4.1. Running this version (didn't delete Xcode
10). Can run either version
Verified Swift version was set to 4.1 (4.2 was not an option)
Deleted Derived Data folder. File> Project Settings.. Clicked on
right arrow next to Derived data folder. Deleted specific project
file. Also tried deleting entire folder
Here is my long tale of woe: I have been working on a project for about 6-8 weeks, using Xcode 9.4.1 on High Sierra. I am a novice, so I created some simple "proof of concept" apps to learn about text views, attributed strings, web views, etc. Each of these small projects compiled and ran fine.
I combining these features into a single app, and adding a Cocoa Pod library. Again, everything compiled fine. I was debugging simple issues in the code. At one point, Xcode stopped showing correct values in the Variable display for my code. I was reduced to debugging with print() statements, which always showed correct variable values.
I upgraded (?) to Xcode 10, then later to Mojave to try to resolve Xcode's incorrect variable values. Other issues emerged, including known issues with evaluateJavaScript. So I decided to revert back to pre-Mojave to get back to a working state. I used Time Machine to revert back to Xcode 10 under High Sierra.
Now my projects give compile errors. Even my simple proof of concept apps have compile errors. So I've been trying to get back to compilable code.
What else should I try to determine what has changed?
Here is the specific attributed string code that is generating syntax errors:
let titleAttributes = [NSAttributedString.Key.font: NSFont.boldSystemFont(ofSize: 22)]
gives error:
Type 'NSAttributedString' has no member 'Key'
I'm also getting an error on a segue:
performSegue(withIdentifier: "showSecondVC", sender: self)
gives error
Cannot convert value of type 'String' to expected argument type 'NSStoryboardSegue.Identifier'
Apologies for the long post. Under Unix, it's easy to get a user account or app back to a known initial state. It seems a lot harder under Mac OS X...
Thanks for any suggestions!
The problems you talk seem originated by Swift version.
To answer to your question, when you download a new Xcode App (and yes, you can have more than one Xcode app in the same computer) everything is inside the huge app.
All the local data are inside the folder
~/Library/Developer/Xcode/
Where you can find several folders with lot of data. If you have problems with Ide size you could check the "IDEPreferencesController.xcuserstate" that is found inside UserData folder.
Just to get some context here is a screenshot, though you probably gathered this from the title:
Xcode is marking all symbols as undeclared, usually this would be because it doesn't exist or isn't imported, but in this case it was working fine 20 minutes ago and weirdly the project compiles and runs with no problems.
When I compile the errors go away but there is no syntax highlighting, as soon as I start to edit the file the errors all come back. I can work if I remember the exact signatures for anything that I need to use but with the lack of code completion and errors this is very hard.
Notably this is only a problem in a few source files, its not even the whole project. Nothing has changed that I am aware of that could cause this.
Before anyone suggests it, I have tried cleaning, deleting derived data/build folder, restarting Xcode etc...
My colleague is seeing the exact same issue on his machine.
So I managed to fix the offending source files, I just compared their attributes to those of a working source file and it turns out that the problem files included the tests project in their target membership and the working file did not. I'm not sure why this is causing the issue as other projects use automated testing without a problem. Nonetheless this solved it for me, at least until I start writing test cases...
Having updated Swift + ObjC project to Xcode 8 (Swift 2.3) I found 50% or more of the time Xcode does a full rebuild of the project instead of an incremental build.
The changes made are adding simple print statements. There seems to be no logic as to when it performs a full rebuild.
It appears in the "Check dependencies" phase it decides this. On Xcode 7 this did not seem to be a problem.
Has anyone else encountered this?
I have found this works consistently, it will however compile swift files if you modify a header included in the bridging header. It will also do full compile if you switch git branches back and forth.
Firstly make sure optimization level for debug is set to None (Not whole module optimization)
Then, according to https://forums.developer.apple.com/thread/62737 Apple Staff (ddunbar):
We believe that setting:
HEADERMAP_USES_VFS = YES
to true in your project (or for all your targets) may be an effective workaround > for many people. This is not guaranteed to work (which is the reason it isn't > already on by default), but it should work for most projects.
This should be added through "Add user-defined setting" under your target Build Settings.
.
Ok, here's an answer to why it's happening, but I don't know the solution. If you use the "Other Swift Flag" -driver-show-incremental Xcode will output what it decides it needs to compile based upon it's dependancies. You'll see things like:
Queuing EditProfileViewController.swift because of dependencies discovered later
Queuing ChangePasswordViewController.swift because of dependencies discovered later
Queuing JoinViewController.swift because of dependencies discovered later
Queuing JoinProfileViewController.swift because of dependencies discovered later
Queuing FormViewBuildable.swift because of dependencies discovered later
Queuing RadioTextFormView.swift because of dependencies discovered later
Queuing TextFieldFormView.swift because of dependencies discovered later
Queuing AccountProfileViewController.swift because of dependencies discovered later
I'm wondering if this is a swift 3 problem, because I wasn't having this issue before converting. I made a little example project where
FileA inclues a thing from FileB includes a thing from FileC
and even adding a file private change to FileC that's not used anywhere causes FileA, FileB, and FileC to be queued for compilation due to dependencies. I'm going to be testing this example in Xcode 7 later today to see what happens.
So it looks like swift 3's dependency resolution isn't working very well. I've tested this on 2 other swift 3 projects at work, and the same holds true. Make any change in any file, and every file gets compiled. It doesn't feel slow until you start getting to projects with about 15,000 lines of code or so, which may be why nobody is talking much about this. Unless you have a somewhat medium sized swift 3 app, you probably won't even notice that incremental complication isn't working quite right. I'll update if I learn anything more.
Apple released new beta version of Xcode yesterday (Nov 14)
Xcode 8.2 beta 2
And this issue has been marked as resolved in the release note.
Build System
• Xcode will not rebuild an entire target when only small
changes have occurred. (28892475)
It is working for me. The build speed came back as usual.
Everybody who is facing this issue, should give it a try!
https://developer.apple.com/download/
Unchecking "Find Implicit Dependencies" in Edit Scheme > "Scheme" > Build tab fixed it for me for project files. "Copy swift standard libraries" still takes forever..
This is similar to another question that wasn't really answered: Xcode 3.2: Build & Analyze never finds any issues
I used XCode's Build and Analyze for the first time on a large project and came up with a number of analyzer warnings. I corrected a few and wanted to verify my changes were being 'accepted' by the analyzer. I didn't even look at warnings in a number of files. But when I re-run Build and Analyze, all the warnings are gone.
I have tried: changing my compiler to LVVC GCC 4.2, switching from a debug to a release build, cleaning all (repeatedly), and quitting and reopening XCode. I just can't get the old warnings back.
Build and analyze only analyzes your modified files.
Go to your project settings -> build tab. And check 'Run Static Analyzer'. This runs a full check on all files on each build.
It is how XCode built with. Whenever, you build the project (even using build & analyze), it will build only those files which are modified before the last build. So if you want to have your old warning & analysis result back, do clean all targets from build menu & again build.
I had a similar issue some days ago. I had plenty of warnings, and after some changes in the code the analyzer warnings disappeared. Even a clean build could not bring them back.
By a coincidence I changed the message filter in the build log from Issues Only to All messages.
And there were plenty of messages related to the disappear of analyzer results. The analyzer complained that he could not analyze my files. I'm sorry I don't remember the correct message.
As far as I remember I put some code into the .pch which confused the analyzer completely. After I changed a lot of stuff analyzer was happy again. Magically. I still don't know why that happened and I can't reproduce it.
For whatever reason, none of the solutions above worked for me. The only way I could get the warnings back was to open the project with XCode 4 and analyze it there. I am taking screenshots so I don't lose these warnings. I hope the analyzer works better in XCode 4 in the future.