I was testing a GPX file with Xcode. I read this tutorial and downloaded this file. Edited my scheme and added the GPX file as a custom location.
Then I decided to change the GPX file. I added the modified GPX file to Xcode. My Xcode crashed. I reopened and added again and it crashed again. I removed all GPX files in my folder and tried adding again, but it crashed again. I cleaned build, cleaned derived data, reset my simulator, restarted my mac. None worked. So I just forgot about adding the GPX file.
Looking into the crash logs of Xcode this is partially what I see meaningful:
ASSERTION FAILURE in
/Library/Caches/com.apple.xbs/Sources/DVTFrameworks/DVTFrameworks-11754/DVTFoundation/FoundationClassCategories/DVTNSStringAdditions.m:1110
Details: (basePath) should not be nil
I also looked into this Apple Forum thread. But that wasn't helpful.
I also asked a friend of mine to look into that folder and share their file with me. They looked but said they don't have such a file, and yet they don't have any errors :(
So then now I opened another project (I never added any GPX file to this). I'm trying to change the location on the simulator. I set it to Freeway drive. It only enforces a momentarily location update, after that it switches back to Custom Location.
So I did all of the above and also uninstalled Xcode and had in reinstalled. Still same issue, can't change simulator location!
Has anyone had any similar experience?
I'm not sure but I think for things that can be modified from multiple places of your Xcode: You have to go to ALL entrypoints that you can change and just tweak it back and forth see if it works.
I was changing the location from simulator itself. It wasn't working. So I went to:
Edit Scheme >> Options >> Allow Location Simulation
From there I just changed the location between different locations. Quit simulator and all of a sudden I was able to simulate to Freeway drive on my simulator. Haven't tried adding any GPX file yet. Most likely I won't! The issue was too much of a headache!
All you need to do to fix this immediately is to switch Location Services (device or simulator) off and then on.
Settings -> Privacy -> Location Services
Related
I have tried cleaning the simulator but it again occupies 6gb disk space on my Mac.
Can anyone suggest manual cleaning?
If the objective is to free up disk space occupied by Xcode-related and simulator-related caches and data, and not just iOS support files, there are other folders you can look into to consider removing files, besides ~/Library/Developer/Xcode/iOS DeviceSupport/ and ~/Library/Developer/Xcode/DerivedData that have been mentioned in the other 2 answers so far.
~/Library/Developer/Xcode/Archives/ contains data from your builds that can be helpful in the process of symbolicating/debugging deployed apps, but could otherwise be removed. Thankfully, it is organized by date, so you can choose to keep specific folders inside it, and delete the rest
~/Library/Developer/CoreSimulator/ contains simulator related data. It includes a Caches folder and a Devices folder. If you no longer need to run your apps on certain devices, you may consider removing those devices' corresponding folders in the Devices folder. The Caches folder may grow over time as well, and you can remove contents from there, and they should be regenerated as needed.
If you've been using this machine for some years, it may be worth looking for ~/Library/Application Support/iPhone Simulator. The simulator related files used to be there until around Xcode 6. So you may have files still there that you might want to delete (I did, on some older Macs some years back)
There's an Xcode specific cache (not about simulators), ~/Library/Caches/com.apple.dt.Xcode, which should be regenerated as needed, but may be less useful to clean up.
You could also consider running DevCleaner from time to time to remove unnecessary Xcode-related files.
Delete the contents of "~/Library/Developer/Xcode/iOS DeviceSupport/".
Remove all "paired devices" in iOS settings > Developer.
Connect iPhone to the Mac and pick "Don't trust".
Since the above is not okay for iTunes syncing etc, try the following:
Delete the contents of the folder "~/Library/Developer/Xcode/iOS DeviceSupport/" and then right click > get info > lock the folder.
Locking the folder will stop Xcode from copying the simulator files from the iPhone to that folder next time you connect them.
https://apple.stackexchange.com/questions/380024/how-to-stop-xcode-downloading-ios-support-package-of-my-iphone
It is possible that Xcode starts downloading it via nsurlsessiod so you can block it either
by using a firewall
https://apple.stackexchange.com/questions/393689/how-to-stop-catalina-from-contacting-apple-servers-when-executing-programs/393698#393698
Or by renaming the binary as explained at the link below. (I haven't tried it)
Xcode simulator constantly download something
Command-Option-Shift-K to clean out the build folder. Even better, quit Xcode and clean out ~/Library/Developer/Xcode/DerivedData manually. Remove all its contents because there's a bug where Xcode will run an old version of your project that's in there somewhere
By following this steps you can do....
For user who are not able to find library/developer path.
open Xcode( i am using Xcode 13) -> file -> workspace setting -> there will be a path at center of modal -> click on arrow button next to path -> on clicking it will open up the folder.
Got a weird scenekit asset problem... I’ve got an assets file (catalog.scnassets) that seems to be fine in Xcode. I’ve added to it a dae file which also opens fine in Xcode.
However, the file doesn’t seem to get copied into the app bundle when I build (mac app), even though the build logs show it happening:
copySceneKitAssets: Copy plants.dae
copySceneKitAssets: Running scntool on /Users/jason/Library/Developer/Xcode/DerivedData/FirstPersonGame-fxynipfnexmczbgnujwuiqxtiogd/Build/Products/Debug/FirstPersonGame.app/Contents/Resources/catalog.scnassets/plants.dae
When I check that directory in the build folder, catalog.scnassets is there, but it’s empty. Any ideas what might be going on?
Here’s what the file looks like in Xcode’s Identity inspector:
It’s simple!
I was seeing a bunch of warnings like:
scntool: warning: Could not load ModelIO.framework ((null)) (etc)
which led me to this StackOverflow post which solved it for me.
In short: check in Xcode Preferences -> Locations. For me, the “Command Line Tools” had nothing selected (somehow!), so selecting a value there (in my case, Xcode 10.1), then doing a clean build, fixed the issue.
Had the same issue on Xcode 11.3.1 but command line tools are set. Had to uncheck "prefer compressed textures" to make Xcode import the file. This will also make a json file to show up!?
I noticed something odd today. I have an application that writes/read data to a .plist file, and when I deleted that file and left all my code in my implementation file the same, I ran the application in the simulator and it was still able to read/write data to this deleted file.
However, if I try to read data from this deleted file in another view controller, they cannot find it. Very very strange.
Is this a known issue in Xcode, or is there something I am probably doing wrong?
If I need to provide some sample code I will, just let me know.
The simulator loves to do this kind of thing, Try clicking "Reset Content and Settings" in the simulator, and cleaning targets in Xcode command-shift-K. Now if that doesn't completely do it you may have to restart Xcode. Another thing I've noticed when working with a .plist is that sometimes if the .plist is deleted and the code is intact, when you execute a write command it has created to the .plist file to write to.
EDIT:
I am running a "old" Xcode 3 project in Xcode 4 and code sense is not working for my own classes. I have tried following:
Clean/rebuild
Remove Derived Data
Installing 4.3 documentation
Restart
Without any luck.
Sometimes the code sense works but mostly I just get "No Completions".
Try this:
Open Organizer then Project Tab.
Clear the "Derived Data". Xcode should re-index your project then and code sense should work. At least worked for me.
I know this is late, but for reference: http://sealedabstract.com/code/when-xcode-4s-code-completion-autocomplete-breaks/
Close the project, leaving XCode still running.
Open XCode’s Organizer window, go to the Projects Tab, select the correct project, and hit the Delete button next to “Derived Data”.
Quit XCode.
Navigate to your project’s .xcodeproject file in Finder. Right-click, choose “Show Package Contents.”
Leave the project.pbxproj file, but delete the project.xcworkspace file, any .pbxuser files, and the entire userdata folder.
Open the project in XCode. You will see XCode riding high on the CPU usage for around 10-60 seconds, depending on the size of your project. The activity window will say “Indexing”
When your CPU spike returns to earth, code completion will be working again.
There's a lot of deleting going on there so please be careful, but this definitely worked for me.
I've been doing this, and it's worked multiple times for me (after trying all of the above previously).
Edit: Now I just hit space, backspace (the mac version) and rebuild... works nice. Then, remember to scroll (sometimes the colors don't show up until you scroll somewhere)
Find your prefix file: "ProjectName_prefix.pch".
Comment out some line. (basically change it)
Build your project, doesn't matter if it fails or not.
Uncomment it.
Build again.
I'm betting only step 2 (modify the prefix) is what does it, but these essentially get you back to running. Suddenly everything magically recolors itself and completes functions.
Good luck if that doesn't fix it, perhaps try doing this to your dependency pch files (three20 or FB api's)
Clearing the "Derived Data" only works temporarily for me. I have to do it and then restart Xcode like 3-4 times each day to get code sense working again.
I found out the real cause is in the Target's Build Settings. I moved everything from Header Search Paths to User Header Search Paths and it is fixed. In my case, the framework I'm working with is RestKit.
BTW, I came up with this because I was adding another project (QuickDialog) into my project and I was curious that it is using User Header Search Paths, but not Header Search Paths. Here is the difference between them.
You can able to fix that issue by change build settings like this, PreCompile Prefix Headers :NO
FYI, if one file doesn't have code sense but the rest of your project does, check that its added to a target. Once I did that I got code sense back in that file.
It's been ages but the answer is just to move the code into a new folder and the code sense should be working now.
This happened when I added a new Objective-C Class and the code sense doesn't work only on the newly added .m and .h files (on XCode 4 latest update during this post).
Close all xcode windows
Delete all your projects from xcode>window>organizer and restart your project. It will now sense and index your project properly.
I wrote about it in detail here.
Basically my fix was that with localization. I upgraded from xcode 3.2.5 to xcode 4 and then screwed around with built in interface builder and turned on localization for a XIB file accidently which placed my source files in en.lproj directory. After moving them back to Classes folder it worked perfectly.
Again, for the sake of helping others with this issue which, in my case, happened upon upgrading to Xcode 4.3.
Of course I tried the solutions offered in this post, and none of them worked. But the suggestion to move the location of the project in Finder brought back some Code Sense, but the suggestions didn't make any sense.
I ended up deleting my project and re-cloned it from the git repository.That brougt back Code Sense for me...
I open a second project in the background whenever my Xcode's code sensing stops working (it usually works the first time i open the project but after a while code sense no longer works). So what i do is to open a second project in Xcode. Xcode will start indexing the second project and magically the code sense for my main project is back.
Running Xcode 4.3.1 on Lion
Hope this helps someone.
From this comment here I was able to debug the problem on my end, it seemed to be a bad -w flag that the clang preprocessor wasn't recognizing properly. Basically, running
defaults write com.apple.dt.Xcode IDEIndexingClangInvocationLogLevel 3
in Terminal increases the verbosity of the indexer, and should help you track down issues. Open Console.app and look for messages from Xcode, the search string IDEIndexingClangInvocation helped me find them.
For me it happened simply because the file had no target membership. If the first few answers did not work for you, go to your .m file (presumably it's this file that you're having trouble with), open the Utilities view (Edit -> Utilities -> Show File Inspector) and under "Target Membership" check the target to which you want this file to belong.
I've just started playing with Xcode 4, and found that, no matter how I setup debugging symbols in the project, Instruments refuses to display source lines for stack trace items that correspond to my code. In only shows hex offsets and identifies my executable as the owning module. Turning on "Source Location" draws a blank too. This occurs even for the skeleton OpenGL ES project generated by Xcode (File → New → New Project... → iOS → Application → OpenGL ES Application).
This problem only occurs in Instruments (I've tried CPU and OpenGL tracing so far). Gdb picks up debug symbols just fine.
Do I have to do something special to see the source code for stack traces in Instruments, or is this a bug in Xcode 4?
So far, I've:
Changed Debug Information Format from DWARF with dSYM File to DWARF.
Changed Strip Debug Symbols During Copy from Yes to No.
Changed the build scheme to use the Debug build instead of the Release build with Instruments.
The other answers are good long-term fixes. If you'd rather not wait for Spotlight to rebuild its index and just need to get symbols for one Instruments session, you can ask Instruments to symbolicate the current session.
Choose File → Re-Symbolicate Document…
Locate your binary in the list that appears. It should be the same name you see on the Springboard. Select your binary and click "Locate."
Go back to Xcode. Control-click on your .app build product and choose "Show in Finder".
This will reveal the directory containing your binary as well as its dSYM file. Go back to Instruments, navigate to this directory, and select your dSYM file. The easiest way is to just drag the dSYM file straight from the Finder to the "Select dSYM" dialog in Instruments.
Finally, click "Symbolicate" in Instruments. You should now see symbols in the traces rather than hex offsets.
I had this issue today and solved it this way:
Edit scheme
Click on "Profile" on the left (this is the important step)
Change Build Configuration to Debug
That should do it. Note that for whatever reason, the build target is not set to the same build configuration as the profile target and this has tripped me up more than a time or two.
Try selecting a different code signing identity, i.e. provisioning profile, for the Release configuration.
I found out what the issue was, as I had the exact same problem.
The answer comes from: Missing symbol names when profiling IPhone application with Instruments
Ensure that you have compiled your code with debug flags enabled (e.g. -g3).
Execute dsymutil on your binary/dynamic library that you want to be able to access the debug information for.
This generates a dSYM bundle folder, and when indexed by Spotlight the debug information necessary is made available to Instruments.
I suppose in your case, it took some time before Spotlight had things indexed - and when it had, then things magically worked out.
It just started working; no rhyme or reason.
I have spent the last half-hour trying to get it to fail again, in the hope of providing a more useful answer here, but I can't, even after recreating the skeleton OpenGL program from scratch, retracing all of my steps.
I did open the symbolicatecrash script in emacs (It has been implicated elsewhere, wrt this kind of problem), and it started working after I did this. But at no point did I change or save it.
It's a mystery.
One reason for instruments having no symbols could be that Spotlight cannot find the dSYM file. So your change from DWARF with dSYM to DWARF is not a good idea. You should change it back since without a dSYM file, you won't get symbols anyway (at least this seems to be the case for Snow Leopard, I have seen reports that some people also got symbols without dSYM files, however, all those people were using Lion). After making the change, make sure you create a clean build (sometimes Xcode fails to generate the dSYM file on my system for non-clean builds).
If you still get no symbols after all that, something is wrong with your Spotlight database. Try adding the folder that contains the dSYM files after a build to the list of folders Spotlight shall not index and then remove it again from that list. This causes Spotlight to reindex the files.
If this also doesn't help, maybe your Spotlight index is completely corrupted. In that case, try the following on a Terminal:
sudo mdutil -i off /
sudo mdutil -E /
sudo mdutil -i on /
This causes Spotlight to first stop indexing your main hard drive, then delete all index data collected in the past and then start reindexing it. The lines above assume that your dSYM files are located on the main hard drive (and not on any other hard drive or network volume, otherwise you must replace '/' with the appropriate mount point of that volume). Give Spotlight some time to reindex before you try again.
In newer versions of Instruments (I have 5.1.1 (55045)), you can add additional paths to be searched for the dSYMs and source code
Open up Instruments' Preferences, then click the "dSYMs And Paths" tab.
Then add your path to the list.
Here's my environment...
XCode 8.2
Mac OS v10.12 Sierra
I had the same problem running in the simulator, and it was driving me nuts because ALL the standard go-to fixes were not working.
What did it for me was plugging my iPad into the MacBook and running an instruments session against said app on my plugged in iPad. Instruments properly symbolicated my app when running on the iPad, and then continued to work when I disconnected the iPad and ran instruments later in the simulator.
I suspect it had something to do with updating my project to use the following...
libsqlite3.tbd instead of libsqlite3.dylib
libstdc++.6.tbd instead of libstdc++.dylib
I don't know why that would be the case, but that was the ONLY project change I had made before my symbols were lost in Instruments.