Workaround certain anti-malware programs

[chirpnot]

This might break things, but it turns out several Windows libraries like to be loaded at 0x180000000.

This causes a problem, because msys-2.0.dll loads at 0x180040000 and expects 0x180000000-0x180040000 to be available.
A problem arises when Antiviruses (or other DLL hooking mechanisms) load a dll whose preferred load address is 0x180000000 and fits in size before 0x180010000:

1. msys-2.0.dll loads and fills 0x180010000-0x180040000 assuming no shared console structure is going to be needed.
2. Another dll loads and fills 0x180000000-0x18000xxxx
3. msys-2.0.dll tries to load 0x180000000-0x180010000 but it's not available. It falls back to another address, but down the line something else fails.

This bug triggers when using subshells (e.g.: git clone --recursive).

(I guess msys should be able to work around the address conflict, but the code is failing in some way and I'm having a hard time figuring it out, so...)

This addresses git-for-windows/git#3539

[dscho]

A couple of comments:

• Could I ask you to use your real name and email address in your user.name and user.email configuration and then call git commit --amend --reset-author -s, then force-push?
• How did you come up with 0x210347000?
• I cherry-picked two fixes to allow the CI build to start.
• Since the build now succeeds, and since I have no way to reproduce the original issue, could I ask you to test the build artifact?

[chirpnot]

• Could I ask you to use your real name and email address in your user.name and user.email configuration and then call git commit --amend --reset-author -s, then force-push?

Will do.

• How did you come up with 0x210347000?

You mean 0x210040000? Random choice. If you have any scientific-like idea to get a new base address, my ears are wide open.

The only semi-feasible approach imho would be to take a windows install and query all the base addresses of all the exe/dll's and then choose something that's not there, but still...

• I cherry-picked two fixes to allow the CI build to start.
• Since the build now succeeds, and since I have no way to reproduce the original issue, could I ask you to test the build artifact?

I confirm it seems to work. I managed to get .\strace.exe .\cmd.exe => .\lsattr.exe to crash in git-for-windows but not in your CI build.

.\strace.exe .\ldd.exe crashes both, but I think it's unrelated. Could you please try it on your machine?

[chirpnot]

Ok, even rebasing msys-2.0.dll in the broken version, strace lsattr still crashes :/ so I guess it's unrelated. Will do some more differential testing.

EDIT: since the CI build doesn't come with many complex programs, I simply dropped msys-2.0.dll from the CI into git-for-windows and cloned a repo with --recursive. No crash. This increases my gut feeling that the strace thing is another problem.

[dscho]

@orgads since you have access to Windows 7, could I trouble you to test this?

[orgads]

Sure, I'll test it tomorrow.

[orgads]

Works for me on Win7. No crash on git clone --recursive (I didn't try to reproduce with the official version).

[dscho]

Thank you @chirpnot!

[Stmgme]

K