Error while retrieving locks: exit status 255

[MJBrune]

Hey All,

So I am hitting an error when trying to "connect to source control" to a repo that was working on 4.18 and even 4.19 before I reinstalled windows. git LFS is installed and I can even pull down git lfs status, locks and attempt to lock and unlock a file just fine. Nothing is currently locked. I'm currently on UE4 4.19 with version 27.

to be clear the error is when running lfs locks when the first tests run when connecting to source control via UE4 editor and LFS2.

[ArtyMcLabin]

Hey, i had something similar as part of this issue: https://github.com/SRombauts/UE4GitPlugin/issues/64

Specifically, this part:

It was a problem with spaces! very strange, because we have rechecked it 10 times and used ctrl+c and ctrl+v from bash "git lfs locks" output. i have checked the logs and i see that somewhat the plugin indicated that the name is "Brad Weiss " with two spaces. also different member named "alex breger" had the same issue. plugin had indicated "alex breger " with one space. Adding the spaces to the end has solved the problem. It is strange that it have happened to 2/3 of our members however.

This bug was solved by @SRombauts, the author of the plugin however. It is possible that something similar to this happened in your case

[MJBrune]

I tried tossing spaces into my username randomly. Seeing its just MJBrune no spaces ever I don't see any way it could have become something different but I tried a few times without success for spaces on the front, end and randomly in the middle.

Additionally I am not able to connect via the UE4 plugin but can interact with git lfs just fine via the command line and running git lfs locks returns. Setting up a breakpoint of !bResult in RunCommandInternal shows that git lfs locks is returning false.

From my logs:

[2018.05.20-18.26.08:118][841]LogSourceControl: RunCommand(lfs locks):

[2018.05.20-18.26.08:118][841]LogSourceControl: Warning: RunCommand(lfs locks) ReturnCode=2:
Error while retrieving locks: exit status 255

[2018.05.20-18.26.08:118][841]SourceControl: Error: Error while retrieving locks: exit status 255
[2018.05.20-18.26.08:118][841]SourceControl: Error: Failed to connect to source control. Check your settings and connection then try again.

Here is my console output for both git lfs commands status and locks

admin@DESKTOP-ME1R7VD MINGW32 /d/Underflow/git/DataBroker (master)
$ git lfs locks

admin@DESKTOP-ME1R7VD MINGW32 /d/Underflow/git/DataBroker (master)
$ git lfs status
On branch master
Git LFS objects to be pushed to origin/master:

Git LFS objects to be committed:

Git LFS objects not staged for commit:

        Binaries/Win64/UE4Editor-DataBroker.dll (LFS: 862ea40 -> File: 00d5f24)
        Binaries/Win64/UE4Editor-DataBroker.pdb (LFS: 6c02d83 -> File: dfc0256)
        Plugins/BrunesCharacterSystem/Binaries/Win64/UE4Editor-BrunesCharacterSystem.dll (LFS: 4d6966c -> File: 3b41ce4)
        Plugins/BrunesCharacterSystem/Binaries/Win64/UE4Editor-BrunesCharacterSystem.pdb (LFS: 4367f98 -> File: 7d6cc13)
        Plugins/BrunesMissionSystem/Binaries/Win64/UE4Editor-BrunesMissionSystem.dll (LFS: d58f4d2 -> File: 3ee32e2)
        Plugins/BrunesMissionSystem/Binaries/Win64/UE4Editor-BrunesMissionSystem.pdb (LFS: e6c917f -> File: 2be2644)
        Plugins/BrunesSaveSystem/Binaries/Win64/UE4Editor-BrunesSaveSystem.dll (LFS: 91b12ce -> File: 6ff3c5f)
        Plugins/BrunesSaveSystem/Binaries/Win64/UE4Editor-BrunesSaveSystem.pdb (LFS: 0c7e836 -> File: c8cfb59)
        Plugins/DialoguePlugin/Binaries/Win64/UE4Editor-DialoguePlugin.dll (LFS: 2fe3dce -> File: 2fc8d2a)
        Plugins/DialoguePlugin/Binaries/Win64/UE4Editor-DialoguePlugin.pdb (LFS: e389c18 -> File: a429db9)
        Plugins/DialoguePlugin/Binaries/Win64/UE4Editor-DialoguePluginEditor.dll (LFS: 86ebda3 -> File: b859b3c)
        Plugins/DialoguePlugin/Binaries/Win64/UE4Editor-DialoguePluginEditor.pdb (LFS: 1cf4627 -> File: 4c58a5d)
        Plugins/UE4GitPlugin/Binaries/Win64/UE4Editor-GitSourceControl.dll (LFS: fbdc1ed -> File: 96cbae8)

Stepping through the code it seems: git -C "D:/Underflow/git/DataBroker" lfs locks is the full command.

All of the above seems to be correct and even going one further...

That command when I run it from the command line seems to actually work...

[MJBrune]

I solved this by 1) exploring other possible ways to break it in the same way that the plugin was seeing but in my control. 2) git trace and digging.

So as I said before I knew this was focused on git lfs locks command. Additionally and something i may have left out before is that I could see git lfs version and a few other commands run just fine. So LFS was/is installed and was setup correctly. So how was the plugin seeing this error when my mingw32 terminal wasn't?

I booted up into my powershell terminals and git lfs locks command returned that exit status 255 stderr line. So with a way to recreate I started comparing things. First, which git.exe I was using. Indeed they were different. So I figured I just set it to the correct one and close this thing? Right? EZ mistake. Nope. Even though the git.exes were different when switching to the other one I got the same exact error.

So I compared my git lfs env and the looked generally the same... okay but here is where they actually differed. GIT_SSH pointed to plink.exe in mwing and in powershell it wasn't set at all. additionally for GIT_LFS_PATH.

So after setting up all my environments, rebooting, rebooting again because I am on windows and then finally issuing shutdown /t 1 /r because I am on windows 10 and REALLY wanted to ensure I actually rebooted. Went back in and got Error: Exit Status 1.

Pageant was running but didn't have the key. So throwing the key into pageant then finally hitting the connect to source control button and that means it worked and magic is back!

@SRombauts Take away from this issue is: May we get some clearer errors? I know you actually are just passing errors directly from git.exe and etc but maybe the plugin can contain some sanity checks for environment variables and etc. Lastly it would be useful to be able to tell the plugin to run GIT_TRACE=1 as a temporary environment variable and get that output from git.exe a bit more verbose when we need it?

Anyways laying this out was useful and hopefully shows others that it's probably just an authorization issue.

[SRombauts]

Hi @MJBrune, sorry for not even answering you in the first place, I have been working through the weekend in preparation for a demo to an investor today, and I am globally far less available than I used to be.

Sadly, I would not have been of a great help, since this kind of issues cannot be diagnosed remotely. And you did a great job!

Thanks for your detailed explanations!

[MJBrune]

No problem at all. I totally understand. Only thing I can hope for is my few hours of work weren't wasted completely. (that this will help someone and save someone time.)