Since a few days ago, I've been experiencing a repetitive crash on Xcode every 3-8 minutes.
The only tangible thing I can find in the crash logs is that it always shows:
Crashed Thread: Dispatch queue: DVTSourceControlGitXPCClient :: Proxy Completion Queue
It seems to be Source Control related, but I wonder how?
I will add everything related to my current project in case it is relevant:
Xcode 14.2 (14C18)
Using Source Control with GitHub
Swift targets iOS and macOS
SPM
It seems like some folks are experiencing a similar issue, as seen on the Developer Forums
Any leads as to why or how to solve it?
After some struggling I decided to check how was git doing, directly from the Terminal.
It turns out there were some things that didn't make sense, specifically a file I deleted from my project but then added again, was showing as modified, even though I had already committed all changes for that file a few days ago; but I had done it directly from Xcode Source Control.
From the Terminal, I staged all changes and committed them. Since then Xcode hasn't crashed for a few hours yet.
My limited understanding of the problem points out that Xcode had issues staging those changes I made a few days ago, and since then the repository has not been in a "healthy state"; Xcode tries somehow to understand the state of the repository but after a while, it just crashes.
Common scenarios where this could have happened:
A file was deleted
A file was renamed, specially with case-sensitive renames, for example from MyViewcontroller.swift to MyViewController.swift
The solution for me was to just put it back in a "healthy state", aka make a commit directly from the Terminal.
Example
From the Terminal
# navigate to the directory of your repository
$ cd /someFolder/myProjectApp
$ git status
# check that you get "nothing to commit"
# or if there are changes they should make sense
# if some changes do not make sense
# try staging and committing everything
# example:
$ git add .
$ git commit -m "Cleaning state"
Related
I have a repository that utilizes electron-updater for auto update. The weird thing is, it has no any code whatsoever pointing where the release updates are stored (I store it in GitHub releases), but somehow the autoUpdater.checkForUpdatesAndNotify() still works. There is github remote origin but I doubt it's being used by electron-updater to find the repository. I don't use any GitHub token either.
The way I release update:
Increase the version in package.json
Run electron-builder, producing .AppImage
Create new release draft in my repository's GitHub releases
Upload the .AppImage file to the draft's assets and modify the draft's tag
Download the previous release, and then open it
Voila! The update works. But how?
It's worth mentioning that if latest-linux.yml is missing from the latest release's asset, it will throw 404 error and refuse to update despite knowing the latest version's tag.
Here's the repository I'm talking about: https://github.com/SnekNOTSnake/fresh-update/releases
Also, is this how normal people release their electron app? I tried the electron-builder --publish way, but it's troublesome compared to the manual steps above.
Thanks to Caramiriel in the comment section above for the enlightenment.
How electron-updater knows where to find the repository is from resources/app-update.yml inside the produced .AppImage file.
The app-update.yml file is produced by electron-builder using the information from git remote get-url origin (if available).
I proved it by changing the origin's url to https://github.com/SnekNOTSnake/tofu-tracker.git and build the AppImage, and (surprisingly enough) the repo's value became tofu-tracker.
Is there a procedure I can follow that includes running a script in the terminal, to delete all the files under the derived data folder and reliably clean a project?
Sometimes, a project's assets don't always get updated to my simulator or device. It's mostly trial and error, and when I find that an old asset made its way into a test build, it's too late, not to mention embarrassing!
I've looked at this question, but it seems a little outdated:
How to Empty Caches and Clean All Targets Xcode 4
I also checked out this question, but I don't want to waste time in Organizer, if I don't absolutely need to: How to "Delete derived data" in Xcode6?
I've looked at other posts out there, but found nothing that solves the problem of reliably cleaning a project and saves time with a script.
It's basically a two-or-three-step process, which cleans the project of all cached assets.
Of course, if anyone uses this technique, and a project still does not show updated assets, then please add an answer! It’s definitely possible that someone out there has encountered situations that require a step that I’m not including.
Clean your project with Shift-Cmd-K
Delete derived data by calling a shell script (details below), defined in your bash profile
Uninstall the App from the Simulator or device.
For certain types of assets, you may also have to reset the Simulator (under the iOS Simulator menu)
To call the shell script below, simply enter enter the function name (in this case 'ddd') into your terminal, assuming it's in your bash profile. Once you've saved your bash profile, don't forget to update your terminal's environment if you kept it open, with the source command:
source ~/.bash_profile
ddd() {
#Save the starting dir
startingDir=$PWD
#Go to the derivedData
cd ~/Library/Developer/Xcode/DerivedData
#Sometimes, 1 file remains, so loop until no files remain
numRemainingFiles=1
while [ $numRemainingFiles -gt 0 ]; do
#Delete the files, recursively
rm -rf *
#Update file count
numRemainingFiles=`ls | wc -l`
done
echo Done
#Go back to starting dir
cd $startingDir
}
I hope that helps, happy coding!
Another way to delete derived data in Xcode is just by deleting the Derived Data folder.
Here is a visual tutorial of how you can do that easily without using command line: https://www.youtube.com/watch?v=ueEMGXKDBAc
I am having an issue with my application hosted on Cydia.
Users are complaining that the app crashes on startup.
The app uses CoreData, I thought it had something to do with this.
Weird thing is that it works fine using simulator or on my device when testing.
But as soon as it is installed through Cydia it crashes.
Turns out that using "Fix User Dir Permissions" from SBSettings fixes this issue.
Now what can I do about this?
I just had a discussion with the repository guys at BigBoss about this.
I never really got a clear answer, but it looks to me like when Cydia installs your application, it doesn't necessarily set the ownership (explicitly) for your application. That seems bizarre to me. In my case, they were test-installing my app, and seeing that it was owned by user/group = { 1000 / 100 }, which was the linux user id and group id from the machine I was preparing my .deb package on!
I can also see this same behavior if I build a .deb package, deploy it to my own local test repository, and install it with Cydia (pointing at my own repo).
In any case, I explained this to them, and they did something to fix it (without anything more from me).
However, one other option is to manually fix permissions in your post install script. In your .deb package, you would have this folder and file structure:
DEBIAN/control
DEBIAN/postrm
DEBIAN/postinst
DEBIAN/preinst
If you put this in your postinst script, I think it should fix this immediately, without having to go into SBSettings afterwards:
#!/bin/bash
chown -R root.wheel /Applications/MyAppName.app/
exit 0
You can do more than that in the script, if you need other directories created, for example. But, the above will at least suffice to change ownership on the .app directory itself.
This BigBoss link recommends creating additional directories in your app's code, and points out that the installer runs as root, while your app normally runs as user mobile. Depending on what you're doing, it may be better to fix ownership/permissions in postinst (root) or in the app (mobile).
The story:
I've been developing a RoR-app in both my desktop and laptop. It was quite handy to commit changes made on another, push them to github and fetch & merge on other.
The starting point is this: I committed latest changes on my desktop, pushed them to github and then fetched and merged them into my laptop. Then, I made some commits on laptop and pushed to github. Took the changes, merged to my desktop (with --no-ff). THEN, happened the probable source of all mischiefs: I reverted the desktop to commit where it was before the latest fetch & merge. Made some development work with it, committed, pushed to github. In the laptop, I did the revert as well, though I reverted it to a commit which was made somewhere between the latest fetch from github, fetched again and merged those. Some error messages came after reverting desktop and laptop both, but things worked still fairly well and I kept working on both machines.
Until now. I tried to push from my laptop to github, which gives the following output:
Counting objects: 106, done.
error: unable to find 5a2a4ac...
error: unable to find bc36923...
error: unable to find ecb0d86...
error: unable to find f76d194...
error: unable to find f899df7...
Compressing objects: 100% (64/64), done.
fatal: failed to read object 5a2a4ac... : Invalid argument
error: failed to push some refs to 'git#github:username/repo.git'
So, the question is, what exactly took place here?
EDIT: It seems that because of suspending my laptop and moving it from place to place in that state screwed up the hard drive somehow. The fsck output is unavailable because we worked around the problem and kept on working, but IIRC some branches and commits were dangling, including that commit which git failed to read. - Teemu
I have run into these kinds of issues.
Rather than spending hours trying to resolve and fix these issues, my 'solution' is usually to take the code I want, copy it into a new directory, delete the .git files and then create a new github for it and then connect the two as usual.
Although this may not be a specific answer to the details you raise, I find that there can be a number of ways that git/github issues can happen and rather than wishing I was a 'git expert' now (it's happening but it takes time), I do the above and continue with my actual application development.
The problem you have is that you are trying to read objects that are not part of your 'tree'. They exist but they have been orphaned. However, git allows you to merge one project to another so this is one way you can keep your commits without starting again, something like the following:
git remote add -f somename git://somegitplace.com/user/some.git
git merge -s ours --no-commit somename/master
git read-tree --prefix=ext/somename -u somename/master
git commit -m 'external merge'
git pull -s subtree somename master
Hope that helps. Let me know if not and we can attack it again
I'm developing a web app on Yaws 1.65 (installed through apt) running on Debian etch on a VPS with UML. Whenever I do /etc/init.d/yaws restart or a stop/start, it initializes according to an old version of the config file (/etc/yaws/yaws.conf).
I know this because I changed the docroot from the default to another directory (call it A), then a few weeks later changed it to directory B, and the config file has stayed with B for the last several months. But then, after a restart, it switches back to A. If it switched back to the package default, that would be understandable, but it switches to an old customized version instead.
The funny thing is that if I leave it stopped for several minutes, when I start it again, everything switches back to normal (using directory B). But while it's stopped, if I run ps, I don't see any yaws-related processes (yaws, heart, etc). This problem has survived several reboots, so it's got to be an old cached copy of the config somewhere, but I have yet to find anything like that.
Any idea what could be going on?
Update:
#Gorgapor - I stopped yaws, renamed the config file and tried to start it again. It failed to start. However, I was able to restart a couple of times and this time it didn't switch back to the old version.
I'm completely inexperienced with yaws, but I have a troubleshooting suggestion: What happens if you remove the config file completely? If it still starts yaws without a config file, that could be a clear sign that something is being cached.
For what it's worth, with a quick 5 minutes of googling, I found no mention of any caching behavior.