Cannot fetch from svn repo (2.7.1 on win x64) #650
Comments
|
This information does not help at all. Please provide a MVCE. |
|
Hello nalla, I have an old local repo on my system, which I have cloned a long time ago from svn (1.4). From time to time I update my git installation and had no problems with this svn repo to dcommit or to fetch. But with the newest release I cannot fetch anymore. I have a windows 8.1 x64. |
|
Now, If I tell tell you that I have multiple |
|
Okay, my repo was broken since the last git svn dcommit. Sry. |
|
how did you find out your repo was "broken"? And how did you fix that? |
|
I get the same error on Windows 8.1 64bit, executing The repo itself is ok. I tried with:
Then I tried with:
A memory address conflict? A rebase problem? |
|
I reinstalled 2.7.1.2 two times before I replied here.. also tried 2.7.0.2 and nothing worked... |
|
Are any of you running this as administrator on a domain-joined machine? |
@albertosantini possibly. You can test that by closing all Git windows, opening an administrator cd C:\Program Files\Git\usr\bin
dash -c 'dash rebaseall -p'If the |
|
@dscho Thanks for the details about rebasing. It seems the hypothesis is not correct. At the moment my workaround is git 32 bit. Fair enough.
@dscho At work I am machine administrator on my domain-joined machine. Why? |
Because I stumbled upon this link when searching for the error number: https://cygwin.com/faq-nochunks.html#faq.using.sshd-in-domain |
|
@dscho Well, the context of that faq is completely different, but I explored the idea of permission problems. After a few hours of investigation (paths, permissions, admin grants, reboots, etc.), I didn't get any result and I didn't get any evidence to reproduce the problem. Also the latest version,
Recap. I have been using portable 64bit installation on Windows 8.1 64bit. |
Oh! The portable Git! Did you run the |
|
Indirectly I can confirm it: if I try to delete the archive just after the extraction, I cannot do it, because the script is running; to clean the folder I need to wait a few seconds. :) However I tried to install also the release with the usual installer and I get the same error. It seems the only solution at the moment is 32bit release. |
|
Maybe running ProcMon will shed some light into the issue?
Please help me figure out a fix so that 64-bit works, too. |
|
After investigating an overhelming number of events with ProcMon, the only things I noticed is a different pattern between 32bit and 64bit. In the 64bit there is a buffer overflow: in ProcMon domain it means there is a request of memory allocation; indeed the same call later has a SUCCESS result. However in 32bit there is not trace about this allocation. I cannot compile the project, but it would be interesting if the issue is related to the following PRs: |
|
@albertosantini sorry that I'm not really helpful as I don't have much time to test (and I can't run ProcMon without also rebooting my system as it conflicts with any app using WinLicense) Since my Git is installed in |
|
I have the same problem.. |
Please note that mentioning that something did not help (without going into anything close to resembling any sort of detail) is not helpful in and of itself. 😃 |
|
Might be useful to know that git 2.7.4 on cygwin is affected by the same issue, as well as the just released git for windows 2.8.0. |
|
@p91paul thank you for your feedback. Please note that debugging this issue is very involved. Any help is appreciated. |
|
Is there something (logs, debug traces, etc) I can get to help you? |
|
@p91paul I am afraid that it will not be that easy to help debugging this. When I said it is very involved, I really mean it. In order to make sense of the problem, you first have to pinpoint where things go wrong. With MSYS2 software that typically means that you have to rebuild the software with debugging information, and frequently not only that, you also have to insert debug print statements (you need those when the stacktrace that you get after the program crashed is useless). Then you need to run the entire failing command again, trying to figure out at which debug print statement things go south. Then you need to insert more debug print statements that verify that it is there that things go south. Lather, rinse and repeat. If you are up for some hard-core debugging, I can assist you. If not, I am afraid that this ticket will have to wait until somebody steps in and does what is required to diagnose and fix the bug. (Side note: As the issue occurs only with large repositories, and only on 64-bit systems, it is quite possible that the culprit is something as innocuous as using some undeclared function that wants to return a pointer; I recently fixed such a bug that could cause nasty crashes on 64-bit.) |
|
@dscho I have this issue stable reproducible right now. If you can direct me what to do - I will try to help. I have git repo of just 6 files, less than 2 Mb total (though SVN repository from where one folder was cloned through git svn is quite large). |
|
@ivan-danilov good! Here are the pointers: First of all, you will want to install the Git for Windows SDK and verify that you can replicate the error. Then you probably want to run Process Monitor while replicating the error and try to figure out from its output whether there is anything obvious going wrong (such as: symbols not found in a DLL, transitive DLL not found, etc). If the bug is still repeatable and Process Monitor does not show anything obvious, another option would be to set the Here's hoping that you can find the root cause! |
|
While installing SDK: We have traffic inspection at office done via internal trusted certificate, effectively man-in-the-middle. Is there a way to get all required files offline or maybe download them at home and install at office afterwards? |
|
With Not sure, possibly it is the result of SDK absence maybe? |
|
I can add the perl stacktrace obtained with Carp.cluck Obviously the fork failed message moved to line 412 because on line 411 there was a So it dies calling |
This looks more like the
This probably means that already the
Right, and as
The second error simply translates the /* Start thread, and then wait for it to reload dlls. */
resume_child (forker_finished);
if (!ch.sync (child->pid, hchild, FORK_WAIT_TIMEOUT))
{
this_errno = EAGAIN;
error ("died waiting for dll loading");
goto cleanup;
}So here we are diving deep down into Cygwin internals (keep in mind that the MSYS2 runtime we use is a close fork of the Cygwin runtime, so all the same caveats apply). The thing here is that POSIX has no The code you are seeing here is the last part of Cygwin's And it is here that things apparently go wrong. Since the timeout is 300 seconds (i.e. 5 minutes), and since no such delay was reported, I will just go ahead and assume that the problem is something else than the reported timeout during DLL loading (which is only a best guess on the error message's part, anyway). So here is the code of the bool
child_info::sync (pid_t pid, HANDLE& hProcess, DWORD howlong)
{
bool res;
HANDLE w4[2];
unsigned n = 0;
unsigned nsubproc_ready;
if (!subproc_ready)
nsubproc_ready = WAIT_OBJECT_0 + 3;
else
{
w4[n++] = subproc_ready;
nsubproc_ready = 0;
}
w4[n++] = hProcess;
sigproc_printf ("n %d, waiting for subproc_ready(%p) and child process(%p)", n, w4[0], w4[1]);
DWORD x = WaitForMultipleObjects (n, w4, FALSE, howlong);
x -= WAIT_OBJECT_0;
if (x >= n)
{
system_printf ("wait failed, pid %u, %E", pid);
res = false;
}
else
{
if (x != nsubproc_ready)
{
res = false;
GetExitCodeProcess (hProcess, &exit_code);
}
else
{
res = true;
exit_code = STILL_ACTIVE;
if (type == _CH_EXEC && my_wr_proc_pipe)
{
ForceCloseHandle1 (hProcess, childhProc);
hProcess = NULL;
}
}
sigproc_printf ("pid %u, WFMO returned %d, exit_code %y, res %d", pid, x,
exit_code, res);
}
return res;
}My best suggestion would be to rebuild the MSYS2 runtime with all of these My hunch is that the problem might have something to do with running out of file descriptors, maybe because no-longer-needed ones were not closed properly. |
That's right. I captured what is going on in procmon for all processes under bash.exe process tree. You can take a look at https://www.dropbox.com/s/hsnct0i4of4jsx9/GIT-SVN.ZIP?dl=0 - not sure it helps much, but Process Tree view looks somewhat promising - shows what was executed at a timeline. I believe each of the last three perl.exe processes (separated by a large time amounts, probably went to error handling) printed an error message. |
|
I am not going to be of much use here, but just wanted to say I am experiencing this problem on Windows 10, x64, with versions:
When doing a I have confirmed that the 'dll' I've heard also that this problem is only on x64 and not x32. Call me stupid but could this be something to with an X64 binary being loaded into a 32bit process or vica versa? |
|
Confirmed that uninstalling the x64 version of |
|
~Was just wondering if the |
|
@dazinator you could try to replace the files in question with the versions from https://github.com/dscho/MSYS2-packages/releases/tag/subversion-1.9.4-2 and test again. There is a known breakage for which we try to get a fix into the official |
|
@dscho - Just tried replacing the binaries from the x64 install of 1.9.0 with the ones from the releae you linked to However I think there are 2 different versions of I noticed in the package Hopefully I am making sense here, like I say I don't usually deal with native stuff. |
|
@dscho - actually I should just be able to grab them all from an x32 bit 1.9.0 install.. I'll try that |
|
Ok I got to stop - because I have absolutely no idea what I am doing, with my maverick and reckless actions :) To summarise what I have established:-
My suspicion is |
|
Yeah, you cannot mix and match 32-bit and 64-bit versions: 64-bit perl will not be able to use 32-bit The problem you reported is most likely the dreaded DLL base address problem. |
|
@dscho is it possible for the 64bit version of git for windows, to use a 32 bit version of pearl and thus the working 32 bit perl dll's do you think? Just throwing it out there because I am in complete ignorance of the code base and everything about it. Guessing this is probably a big no-no |
|
Also can this issue be re-opened? Or is this a duplicate? |
|
Nevermind looks like this issue is superceded by #708 |
I noticed the `osx-gcc` job failing in git-for-windows#647 so I found this upstream fix from @peff. Merging now to unblock PR builds in `microsoft/git`.
Hello,
I have a problem with the newest release of git on windows x64 during using git svn fetch.
I had no problems with the version befor (2.7.0.windows.1).
Thank you!
The text was updated successfully, but these errors were encountered: