I am trying to run git from the command line on my Windows 7, 64 bit machine. It works fine for the most part. I tried pushing my local changes up to my private repository in the cloud.
The command I am trying to run is git push origin master
I use Cygwin 6.1 and it is causing the following error. Presumably related to the fact that I am running on a 64 bit machine
0 [main] git-remote-http 6168 fork: child -1 - died waiting for longjmp before initialization, retry 10, exit code 0xC0000135, errno 11 error: cannot fork() for send-pack: Resource temporarily unavailable
I followed the suggestions here to update my rebaseall file and reran the rebase command. But it didn't really seem to have helped.
Can anyone else reproduce the problem or have found a solution?
Thanks in advance for the help.
The Cygwin mantra I used is "fork failures are rebase issues". longjmp is not the issue, fork is. Rebase is the only solution unfortunately. In the past I have used custom scripts to build the rebase list. I do this because you may be missing some DLLs, especially if you have hand-built stuff. You can build a list with find and then pass it in to rebaseall with -T. You should also consider trying a different base address other than the default one in rebaseall, look at the -b option. 64-bit machines seem to require larger spacing than 32-bit ones and so the default didn't work well for me.
Also if you change any DLLs on your system at all, you'll need to rebase again.
Note: Even after all this fork can still fail in Cygwin. Virus scanners inject their DLLs which screw things up and Windows address space randomization doesn't help either.
The answer mfisch gave worked wonders for my problem.
A quick google search yielded this result which let me git push again in no time at all. The required packages came with the default cygwin install, so I didn't even have to install anything.
The other alternative is to use the msysgit distribution, which will allows you to make any git command without depending on the cygwin environment.
See also "Difference between msysgit and 'cygwin + git'?".
Related
For a long time, I was under the impression that Git on Windows was very slow. I've seen several articles and SO posts that revolve around that. I've tried several of them:
Disabling the __ps1 stuff
Adding exclusion in Antivirus software (Windows Defender)
Using installer instead of portable version
Today, I found another SO post which suggested using GIT_TRACE=1 to debug what's happening when a git command runs. Here's a sample output:
19:47:42.207480 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
19:47:42.211593 git.c:455 trace: built-in: git diff 0.todo
19:47:42.260647 run-command.c:666 trace: run_command: unset GIT_PAGER_IN_USE; LESS=FRX LV=-c less
diff --git a/0.todo b/0.todo
index 740ccba..1db29d6 100644
...git diff output...
This shows that the git commands themselves are not taking a lot of time. The last action which depends on less is the one taking most of the time.
I verified this by running the less command directly. It's slow. But if I run it once or twice, the subsequent runs are normal. If I close that command prompt and open a new one, the first run is very slow (5+ seconds).
I ran some other commands found within C:\Program Files\Git\usr\bin: base64, ls, etc. Same result.
So, I've concluded that this folder is the cause for the slowness of git commands on Windows.
But, how do I go about fixing it? How should I debug? What more information can I provide here that'll enable someone to help me?
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll
I am trying to use git svn clone with cygwin 64 on a svn repository and I keep getting this message which errors out:
Temp file with moniker 'svn_delta' already in use at /usr/lib/perl5/vendor_perl/5.14/Git.pm line 1024.
How do I resolve this issue? I found this one that's related to macs, but I'm on windows. The two main answers there say:
"Change ~/.subversion/servers" I don't know where this is in Windows 7.
"a general upgrade to latest Git (1.8.5 should be out next week) and latest SVN 1.8 can help make things run smoothly" But in cygwin I'm stuck with git version 1.7.9.
I have a feeling the latter isn't a necessary step or else everyone using the git svn bridge in cygwin would be complaining like me.
The first answer I linked to in my question had the solution. I had to find the .subversion/servers file which existed in my cygwin path of ~/.subversion/servers. I also have a SilkSVN client and I changed that servers file there too. I found the path for that in this answer.
I'm building a thing that processes incoming file packages, but I have the rather serious problem that I can't sanitize the incoming data until it's in a position to break the processing, and it breaks it such a way that simply restarting the process doesn't fix it.
My current best solution is to git clean -fdx and git checkout . the project directory the process uses, which works like a charm, except that sometimes git clean asks for user input ("cannot unlink file. Retry?"), which causes a problem for automation.
Is there a way to put Git into a non-interactive mode? I need to do this from inside Ruby on a Windows machine.
For Windows, this is what worked for me (sets the GIT_ASK_YESNO environment variable to false, stopping git from asking yes-no questions):
set GIT_ASK_YESNO=false
Then when I get those same messages as warnings but it continues as if I said no.
So git clean -fdx works for me as expected without blocking.
yes no | git clean -fdx
yes no outputs no forever and piping that into git clean causes every prompt to be answered with no.
This generally is because of other processes keeping an handle to those files which "cannot be unliked" (as mentioned in "Cannot unlink a file in PHP/Windows").
That means your automated job has to make sure that all running processes are stopped/killed first, before updating the working directory.
Disclaimer, I don't know Ruby.
Per the documentation, and short of coding up a way to kill all the services that are still running (which may be the best route, depending on your solution and what you need to clean in order to test it) the best it seems we can hope for with this command is to make a shortlist of the files that always result in a [Y/n] prompt.
So, when I see the following: Unlink of file 'packages/RavenDB.Server.2.5.2851/tools/blahblahblah failed.
I add the following to my command:
git clean -fdx --exclude=/packages/RavenDB.Server.2.5.2851**
And, it seems to work.
I'm trying to deploy my site using Fabric and Mercurial. In the Windows command line, running hg push works perfectly with no problems.
But when I try writing
local("hg push")
in a fabfile and running it, I get the error:
'"hg push"' is not recognized as an internal or external command, operable program or batch file.
Googling gave me an idea that it might be a problem with the PATH variable in Python subprocesses, for example here: Why would an "command not recognized" error occur only when a window is populated?.
Can you help me out? Is the bug in Fabric or in my own code?
Thanks.
As Chris R mentions, we don't do a ton of Windows support as none of the core devs are Windows users; we have to rely on reports and suggestions from our more savvy Windows users.
It sounds like this could be related to this recently fixed, but not released, bug -- it will be in Fabric 1.0.2 which should be out soon. If you're feeling brave, you can test it out now via:
pip install -e git+git://github.com/bitprophet/fabric#1.0#egg=Fabric
If you then do fab -V, it should say it's 1.0.2a -- if so, running your fabfile may work better. Please let us know if you do this!
It sounds like the you need to add Mercurial to the Fabric process's PATH.
Maybe something like:
fabric.context_managers.path(<path to your hg.exe>)
run('hg push')
See the docs for the path context manager. It wasn't clear if path applies to local commands, but run commands are explicitly referenced.
Neither of the fixes provided worked, but changing
local("hg push")
to
os.system("hg push")
solved the problem.