Closed saschanaz closed 2 years ago
Crash report:
fast-import crash report:
fast-import process: 9876
parent process : 1
at 2022-01-11 15:19:01 +0000
fatal: Unsupported command: error
Most Recent Commands Before Crash
---------------------------------
* error
Active Branch LRU
-----------------
active_branches = 0 cur, 5 max
pos clock name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Inactive Branches
-----------------
Marks
-----
-------------------
END OF CRASH REPORT
git cinnabar --version
?
Sorry, forgot it 😅
> git cinnabar --version
0.5.9a
module-hash: 5e3702f55a47d0bbe5d819cb93d960888138b9be
helper-hash: 35b90b2bf83cfb025e256ca1d65dc8763437b517
I suppose if you do git show refs/cinnabar/metadata^5:ae/dd/79826df584eafb9e63cce0bb9894c03e5485
, it fails?
Hmm, not sure this is what you expect, but anyway:
> git show refs/cinnabar/metadata^5:ae/dd/79826df584eafb9e63cce0bb9894c03e5485
fatal: invalid object name 'refs/cinnabar/metadata^5'.
> git show "refs/cinnabar/metadata^5:ae/dd/79826df584eafb9e63cce0bb9894c03e5485"
fatal: invalid object name 'refs/cinnabar/metadata^5'.
This doesn't make sense. Did you run that in the same repo as the original pull?
Sigh, I'm dumb. I was in git-cinnabar directory, so here it is again:
> git show refs/cinnabar/metadata^5:ae/dd/79826df584eafb9e63cce0bb9894c03e5485
fatal: path 'ae/dd/79826df584eafb9e63cce0bb9894c03e5485' does not exist in 'refs/cinnabar/metadata^5'
Ok, so this looks like is the same as #207, but it should have been caught earlier. Do you know what version of git-cinnabar you were running in early december? Can you send a bundle created with something like: git bundle create $file refs/cinnabar/metadata --not --remotes origin? (you may want to add any other remote you have with a --remotes too)
Do you know what version of git-cinnabar you were running in early december?
I don't, but git reflog
says:
d573fca (HEAD -> master, origin/try, origin/master, origin/HEAD) HEAD@{0}: pull: Fast-forward
04b8365 HEAD@{1}: pull: Fast-forward
1ffb93f HEAD@{2}: clone: from https://github.com/glandium/git-cinnabar
So there's not many candidates and it's probably 04b8365.
Just shared the file to you.
> git bundle create ../output.gitbundle refs/cinnabar/metadata --not --remotes origin
warning: unable to access '_mobile/_android/_tests/_browser/_chrome/_tp5/_amazon.com/_www.amazon.com/_Kindle-Wireless-Reader-Wifi-Graphite/_dp/_B002Y27P3M/_%5C%22http%3A/_g-ecx.images-amazon.com/_images/_G/_01/_x-locale/_personalization/.gitattributes': Filename too long
Enumerating objects: 9523929, done.
Counting objects: 100% (9523889/9523889), done.
Compressing objects: 100% (4633465/4633465), done.
Total 9523482 (delta 4761222), reused 9519591 (delta 4758211), pack-reused 0
Hopefully that warning shouldn't be too important here....
What remote(s) do you have on the repo? it seems to have stuff that is not in mozilla-unified.
Edit: Oh, it's a gecko-dev graft clone.
Interestingly, your repo shows this type of corruption has happened multiple times, some of which should have been caught earlier than now.
Run git update-ref refs/cinnabar/metadata d17ccfe5efcfe17051429c3bba1e27ebee8d9bcd
and update your remote again. This will fortunately not affect the commit sha1s. If you have a fast internet connection, you may just want to use git cinnabar reclone
.
Since this is the same as #207, I could close this issue, but I'll keep it around until I figure out why this wasn't detected at the moment the corruption happened.
Some really weird things happened in this repo, and I have absolutely no idea how. I also have absolutely no idea why, if you were indeed using 04b8365, you didn't get errors from the code added in 3ecabe6d8ae6926d0ba10cca53996fb167953dbe, because if I do hack git-cinnabar to make it pretend it generated the broken metadata, the test correctly finds the breakage when updating from the last correct state to the corrupted state.
One possibility in my mind in that the version mismatch of helper executable right after updating cinnabar, since I frequently forget doing git cinnabar download
and then see the warning. But no idea that actually affected anything.
Since this is the same as https://github.com/glandium/git-cinnabar/issues/207, I could close this issue, but I'll keep it around until I figure out why this wasn't detected at the moment the corruption happened.
We figured that out in #295 and it's now fixed in master.
This somehow started today.