Freeze when adding repository

[slopez31]

Hi everybody,
I have à little issue when i'm a trying to add a collaboration workspace (actually it's not on every computer 2/3). (with last beta version 3.2).

Archi freezes during "Fetching..." message

Killing "Windows Host" Subprocess unblock and download the map.
After this and until now everything seems to be fine.

My git server is a gitlab on premise server.

Thanks and good work to all.

[Phillipus]

I won't be able to diagnose this without more information. Can you try and narrow things down?

[slopez31]

Hello Phillipus, I think i can reproduce the issue, what can i do to help you to debug ? Maybe there is a log file ?

[slopez31]

Hi again,
Maybe this will help you

the bash command is called with : bash --login -c "which git"
And if the linux sub-system is not deployed it wait for a key to be pressed.

[Phillipus]

Need to know:

• Archi version
• Model Repo version
• Steps to reproduce - what exactly leads to the freeze?

[slopez31]

Archi version 4.2.0
Model Repo Gitlab : GitLab Enterprise Edition 10.5.4-ee
Windows 10 enterprise Version 10.0.16299 Numéro 16299

The steps are simple, with fresh install I just used the green button "Import remote model to workspace" , and fill the form with server, user password. and finaly fhe "Progress" windows stop on fetching and archi is completely freezed.

[Phillipus]

Which version of the the Model Repo Plugin?

[slopez31]

[Phillipus]

Why is "Windows Host" Subprocess running under Archi? I dont's understand what all the Bash and other stuff has to do with this. Is this problem only on this machine with all this stuff? You have to narrow down the problem, because I can't diagnose it.

[slopez31]

I think the probem is after this

Maybe the subprocess is invoke in the jgit lib . Unfortunately, I'm not skilled enough to debug deeper or to propose a patch.
I'm going to continue to kill manually the subprocess, it's a good way to avoid the issue.

Bye and thanx a lot for the plugin

[Phillipus]

OK, I found out that JGit sometimes invokes bash to find global git settings:

https://www.eclipse.org/forums/index.php/t/1031740/

Perhaps it is getting stuck here. Need to investigate why.

[Phillipus]

Looking at that JGit code...

If JGit can't find a native git executable in system PATH it then looks for "bash" in the system PATH. If it finds "bash" it will try to invoke it with "bash --login -c which git" command in order to find git. This seems a dumb thing to do.

Workaround would be to install git somewhere and make sure it's on the PATH, or remove "Bash" from PATH.

But we need to figure out why invoking bash is freezing. - I know

What bash have you got installed? OK, I know now.

[Phillipus]

I've filed a bug report for JGit:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=532723

[Phillipus]

@slopez31 You could workaround this by:

1. Open Control Panel, "Programs and Features", "Turn Windows features on or off"
2. In the dialog untick "Windows Subsystem for Linux"
3. Reboot.

[slopez31]

@Phillipus Thanks for the tip.

[Phillipus]

Or install git and ensure it's on the PATH.

The ideal solution is the JGit guys remove the dumb "search for bash" thing.

[slopez31]

Yes i think i'm going to install git.
MIcrosoft command could sending an error code instead of waiting for a key !

[Phillipus]

The code in JGit to determine whether git is installed is simply to try and find the global git config file (if it exists). Searching for any "bash.exe" on the PATH is dangerous:

protected File discoverGitExe() {
	String path = SystemReader.getInstance().getenv("PATH"); //$NON-NLS-1$
	File gitExe = searchPath(path, "git.exe", "git.cmd"); //$NON-NLS-1$ //$NON-NLS-2$

	if (gitExe == null) {
		if (searchPath(path, "bash.exe") != null) { //$NON-NLS-1$
			// This isn't likely to work, but its worth trying:
			// If bash is in $PATH, git should also be in $PATH.
			String w;
			try {
				w = readPipe(userHome(),
					new String[]{"bash", "--login", "-c", "which git"}, // //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$ //$NON-NLS-4$
					Charset.defaultCharset().name());
			} catch (CommandFailedException e) {
				LOG.warn(e.getMessage());
				return null;
			}
			if (!StringUtils.isEmptyOrNull(w)) {
				// The path may be in cygwin/msys notation so resolve it right away
				gitExe = resolve(null, w);
			}
		}
	}

	return gitExe;
}

They should remove the part where they even say "This isn't likely to work"!

[Phillipus]

And I can't even inject my own FS_Win32 class to override this because of their hard-coded FS factory:

	public FS detect(Boolean cygwinUsed) {
		if (SystemReader.getInstance().isWindows()) {
			if (cygwinUsed == null)
				cygwinUsed = Boolean.valueOf(FS_Win32_Cygwin.isCygwin());
			if (cygwinUsed.booleanValue())
				return new FS_Win32_Cygwin();
			else
				return new FS_Win32();
		} else {
			return new FS_POSIX();
		}
	}

[Phillipus]

Seems like this is a known issue for some time with JGit:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=515354

As is usual with Eclipse frameworks, it doesn't look like they'll fix it any time soon.

[Phillipus]

Setting the property "-Djgit.gitprefix=<location of git.exe>" location in the Archi.ini file might be a workaround.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=515354#c24