I received a .crash file from a customer and need to link it to the correct dSYM file. The archive for this product/version was built by another developer using Xcode, and the .xcarchive file put into git for a rainy day (like today).
After reading Analyzing Crash Reports and Understanding and Analyzing iOS Application Crash Reports it isn't clear how this works.
I have done the following:
open the Devices window, "View Device Logs" button
drag the .crash file to the list (we drag a crash log from a different device/user onto our device - this seems wrong but AFAIK is what needs to be done)
In Organizer/Archives, the archive for the needed version is NOT in my list. It was built on a different computer and I have not done anything to bring it to my environment yet
Initially when I was viewing the crash file, it simply had the hex codes
right-click and "Re-Symbolicate" the crash log that I added earlier
Somehow Xcode now seems to know about about my archive. I see method and line number info now, but...
I'm not convinced this is working, and may be linked to the wrong thing.
Q: How does Xcode know about my xcarchive file that contains the dSYM for the version of the crash file? (I would expect it to have to be in the Organizer/Archives list, but isn't)
Q: Is there a better way to import the .crash file? (I would expect to be able to drag it into Organizer/Crashes, but apparently not)
I'm not 100% certain, but I think Xcode uses Spotlight to find the correct dsym file, so it shouldn't matter where it is on your disk.
I think it runs this command:
mdfind "com_apple_xcode_dsym_uuids == <UUID>"
You can also run this to list all dsym files Xcode can find at the moment:
mdfind "com_apple_xcode_dsym_uuids == *"
(Taken from this answer)
Related
I have a MacOS app that I last notarized about a year ago with no issues. This time, however, when I created the initial Archive, the Organizer put it into a section called 'Other Items' instead of in the 'macOS Apps' section with all of the previous Archives. In addition, and more distressingly, when the Archive is selected, the button says 'Distribute Content' instead of the expected 'Distribute App', and pressing it simple exports the Archive or its contents, without running through the automatic notarizing process.
I suspect I have done something in the last year that somehow invalidates my app such that Xcode no longer recognizes that it is an app. I have followed the suggestions at https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues, but that did not provide any relevant clues.
I am using Xcode Version 13.4.1. How do I figure out what is preventing Xcode from offering to notarize the app?
To track this down, I created a new project, and then tried to notarize it. (I didn't actually notarize it, I just made sure that I could Archive it and it showed up in the correct section in the Organizer.) The new project archived as expected, so I knew that I could still notarize somethings; I was just having an issue with my app.
My plan was to copy items from my app into the new project in small chunks, and after each copy, attempt to Archive it. I figured that I would either find the item that was causing the failure (and fix it), or I would eventually copy the entire app without a failure. Either way, I would be able to notarize the app.
The first chunk I copied was all of the build settings. And right there, the new project would not notarize, so I removed and added build settings to binary search which setting was causing the failure. It came down to the RUN_DOCUMENTATION_COMPILER = YES build setting.
In the last year I have been more conscientious about documenting the code, and to actually see that documentation, I had added that build setting.
Comparing the archives created with and without running the documentation compiler, the MyApp.doccarchive file appears in the archive in the Application folder along side MyApp.app, so it appears that Xcode is confused by the "extra" file in the Application folder.
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.
Is there a way to activate Xcode Source Editor option in System Preferences > Extensions? For some reason, it's not showing on my Mac (the last option).
If the Xcode Source Editor is missing from the left pane (see image above), try one of these solutions before resorting to a reinstallation:
In the Applications folder, rename Xcode and then change the name back to Xcode, or move Xcode.app out of the Applications folder, then back in, as described by this Stack Overflow answer.
Move the Xcode app to the Trash and re-install it from the AppStore.
I install the Xcode manually that's why not found on Extensions.
To fix quickly:
Quit Xcode
Rename Xcode in the applications folder temporarily with any name.
Launch renamed Xcode
Quit Xcode
Name it back to the old value ("Xcode")
Go back to Extention you will find the Xcode
The entry is shown if the system detects that both Xcode and at least one Xcode extension is installed. Yet the code to detect Xcode has a few issues.
If you install Xcode first and don't have an extension, the entry is not shown. If you then install an extension, the system re-checks if Xcode is still installed and if yes, it should add the entry. However, the check code will fail in some situations. E.g. if you renamed Xcode.app to something like Xcode_13.4.app (as you need to manage different versions of Xcode), the detection code may not find it. It also may not find it if you moved Xcode to a different location outside of /Applications. And even if not renamed and still in the default location, the detection code sometimes fails and the exact reason why that happens is unknown (it may have issues with certain ownership, certain file permissions, case-sensitive file systems, etc.)
In all these situations, renaming Xcode causes it to be re-detected by the system and then the system sees that Xcode and at least an extension is installed and the entry appears immediately. No need to reboot or start the renamed Xcode; you rename it, you rename it back, and the entry is there and will stay there (even after deleting all extensions, it stayed on my system).
If you first installed any app with an extension and then Xcode, the problem does never appear as in that case you immediately trigger the rename-fix above, because the moment you install Xcode, the system will always detect it correctly (regardless how the app is named or where it is located or any other issue the scan code might have) and detecting Xcode and knowing there is an extension, the menu entry appears at once. The code that detects Xcode extensions seems to always work correctly.
This is probably one of the issues where the Xcode detection code has not been tested very well by the Apple but since it seems to work for the vast majority of users, Apple sees no reason to further investigate why it would sometimes fail.
It will get activated by default if any plugin are added in Xcode.
You have to download XcodeClangFormat plugin from GitHub and follow the installation steps. Then Xcode Source Editor will be visible automatically.
Please refer this link
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'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.