This week one of my standard perl [Strawberry perl 5, version 32, subversion 1 (v5.32.1) built for MSWin32-x64-multi-thread] scripts started failing. I tracked it down to a failing backtick operation.
Investigation showed that all the system-type calls, backtick, qx, pipe open, are failing. I tried building a debug version of perl, and even that fails, as the build process uses miniperl, which has the same problem.
..\miniperl.exe -I..\lib ..\make_ext.pl "MAKE=nmake -nologo" --dir=..\cpan --dir=..\dist --dir=..\ext --nonxs
Can't spawn "cmd.exe": No such file or directory at ..\make_ext.pl line 580.
Can't spawn "cmd.exe": No such file or directory at ..\make_ext.pl line 582.
Unsuccessful make(dist/if): code=65280 at ..\make_ext.pl line 584.
I tried defining PERL5SHELL (full path to cmd, pwsh in place of cmd), turning off malware protection, everything I could think of reverting.
So, the actual question:
Does anyone have a suggestion for how I can track this down? It was working on Thursday, and there have been no system updates since then [OS version 10.0.22000].
I ran into the same problem starting a couple of weeks ago. I use ActiveState perl, so I tried installing Strawberry perl, but got the same problem w/ Strawberry. I also saw the zero length files getting created. This is happening on multiple machines. One is Winver 1909 and the other is 21H2.
A workaround is to use the full path for the program you want to run.
You can also insert the full path to cmd.exe ahead of the program. Try this:
$temp = `$ENV{COMSPEC} /c date /T`;
print "\$temp = $temp";
I've been assuming this was due to a W10 security update, but I really do not know the cause. I am going to write a sub called Backticks() that I could use like this:
print Backticks('date /T');
sub Backticks would return $ENV{COMSPEC} /c #_.
This is a hack, but at this point I do not know what else to do.
Using the Malwarebytes beta (4.5.10.200) version fixes this problem for me.
I ran into the same problem starting about 10 days ago. I thought it had to do with path, but it appears ok. Problem is on 2 machines: Win10 and Win11. The Win11 PC I just purchased a couple of days ago, install strawberry and tested. Same error when I call system(..).
Short term solution I found is to copy cmd.exe from c:\windows\system32 into the directory where the script is running. Not a good solution, but it gets me through the day. I suspect it's some security update made in windows in the past couple of weeks.
Update 6/15/22: I can confirm that Malwarebytes beta (4.5.10.200) version fixes this. However, I had this problem on my Win11 PC before installing Malwarebytes. Maybe it's a problem with Windows Security?
Related
Trying to run a shell script in Git Bash. This particular script requires the Rcpp and RcppArmadillo packages. (creating an R package implemented in C++) Because I am on a Windows system I had to install Rtools40. Upon execution of the sh command I get the error:
fatal error - cygheap base mismatch detected - 0x180316408/0x180317408.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
What I've tried:
Following the instructions in the error message. However, a search for cygwin1.dll comes up empty. Additionally, I have never installed Cygwin on my machine.
Updating R, Rtools40, and Git for Windows to the latest versions. This was much needed (apparently Windows doesn't update these programs automatically sigh) but it did not resolve the error message.
Turning off ASLR protections in Windows Security settings as described in this post and this post.
Deleting duplicate msys-2.0.dll files from my drive. This ultimately worked. I will post the solution in detail as an answer to this question.
Hope this helps anyone who, like me, has been sifting through the many posts that don't fully answer this question.
So here's how I solved this problem. From what I understand, the error message in Git Bash is outdated and deceptive. It references Cygwin, but Git Bash actually uses MSYS2, not Cygwin. So instead of searching for cygwin1.dll, I needed to search my drive for msys-2.0.dll. This file was present in two locations: Git\usr\bin and rtools40\SOMETHING (I don't remember the exact path, but it was associated with Rtools40). As per the directions in the error message, I deleted the version that was older, which happened to be the one associated with Rtools40. That left only one version of msys-2.0.dll on my drive, and the sh command then executed in Git Bash with no issues.
What I'm still confused about: Why hasn't the error message in Git Bash been updated? What's the difference between Cygwin and MSYS2? I know they both impose the UNIX environment on Windows, but are there advantages or disadvantages to one or the other? In the long run, if I want to execute scripts through the command line, is Git Bash sustainable, or should I just create a Linux partition on my machine?
I came across a post on GitHub that mentioned that if you are running into this issue after getting a "Resource temporarily unavailable" error, then the issue is likely that you are running 32-bit version of Git. Install Git 64 bit, and your issue should go away
I was installed cygwin on Windows 7 and when I tried to use dig command, cygwin always return "Segmentation fault ('core' generated). I don't know why.
I've installed cygwin with bind-packets too, but it seems don't work.
Is there anything else to do to make this work? Anything more to install?
Thanks.
Segfault could be caused by manual installations and/or corrupted setup.ini files; try removing the whole cygwin package and running the setup again.
I used to run dig on Windows 7 and it worked(*).
(*) note that the current version (9.11.0-2.P3) does not work for me, i.e. returns no output when querying a Windows-based DNS server.
Posted a bug on cygwin mail list, hopefully it will be fixed.
I updated my cygwin using the setup-x86_64.exe tool (version 2.873) on Windows 7.
I needed to install some additional packages (mostly zip/unzip etc).
Since then, I am getting the following errors when I try to run the Cygwin Terminal (the shortcut points to C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -):
Error: could not fork child process: Resource temporarily unavailable.
DLL rebasing may be required. See 'rebaseall / rebase --help'.
I searched online how to run the rebaseall command they advise in the message. Essentially the recommendation was to start cygwin/bin/dash.exe and run:
bin/rebaseall
I did that a few times, I also used the -v comment, and no errors come back. Still I can't start cygwin.
I also tried running cygwin-x/XWin-server nothing happens.
I looked at the setup logs in cygwin/var/log/setup.log I can't see any error.
I tried to run the setup program a few more times reinstalling some of the packages I already had, that didn't help neither.
Any ideas how can I get that to work?
Here is the fix.
Go to you Windows Defender Security Center settings
Click on App & Browser Control
At the bottom click on the "Exploit Protection Settings" link
Go to "Program Settings" and click on the "Add program to
customize" -> "Choose exact file path"
Navigate to "C:\Program Files\Git\usr\bin\sh.exe" and add it
Override and turn off the following: Mandatory ASLR, Randomize memory allocations (Bottom-up ASLR)
Click "Apply" and now everything should work fine.
Also add these other binaries from the same folder: expr.exe, uname.exe, grep.exe, rm.exe
Good luck,
Gabriel
One of my colleagues has similar errors when openening the terminal from SourceTree (Mingw32), and also got errors when trying to pull, rebase, etc (anything not local). He solved it by uninstalling Sourcetree, using CCleaner to clean his registries (not sure if this was required), rebooted and installed Sourcetree again.
I know this is slightly different from the problem described by the OP, but it might still be solvable by un/re-installing and cleaning of registries, and this might also help future people finding this question with the Sourcetree issue (like I did).
Edit:
Another colleague had the issue as well, and he managed to fix it merely with a restart without any un/re-installation or using CCleaner.
I've been suffering similar problems a lot recently. I've been unable to determine the cause, whether it's due to a recent Windows7 patch or an update in the latest cygwin. I'm in a tightly controlled corporate environment with only limited elevated rights, a lot of anti-malware and encrypted drives. I'm using 32-bit Cygwin at present.
Issues for me began after I installed Git and Git-Svn packages, which required Perl and upgraded various other Cygwin packages as well.
Rebasing using rebase-trigger or rebaseall did not solve the issue for me. Neither did re-installing and setup repeatedly raised errors in the post-install pahse when trying to do the rebase itself.
My first success was by downgrading Perl to the previous version, ie. down to 5.22.1.2 from 5.22.2.1. After a couple of weeks the error returned, perhaps after a compulsory windows update and reboot.
My latest success has been achieved by ignoring the dash/rebaseall script and running rebase.exe directly as follows:-
Create a file which lists all cygwin .dlls in the /bin directory except cygwin1.dll and cyglsa.dll ie.
$ cd /bin
$ ls -1 *.dll | egrep -v '(cygwin1|cyglsa).*\.dll' >rebasedlls.txt
Close all cygwin terminals, if you have any services running which use cygwin ensure that those are stopped also. Check TaskManager and kill processes if necessary.
Open a cmd.exe window (it may help to use whatever elevated rights you can muster), change to the windows path of your cygwin /bin directory (ie. the windows directory of cygpath -wa /bin).
Use rebase.exe directly to find the base address of the cygwin1.dll file:
C:\apps\cygwin\bin> rebase.exe --info cygwin1.dll
/usr/bin/cygwin1.dll base 0x61000000 size 0x00500000
Using that base address and the size as a guide I chose the next whole value up as my rebase base address, 0x62000000. No particular reason for this, just a hunch. (The rebaseall script uses 0x70000000).
Use rebase.exe to fix all the .dlls listed in the file from step (1):
C:\apps\cygwin\bin> rebase -b 0x62000000 -4 -n -v -t -T rebasedlls.txt
So far, so good, my Cygwin is back to a working state again.
From https://chromium.googlesource.com/chromium/src/+/master/docs/cygwin_dll_remapping_failure.md
Handling repeated failures of rebaseall to allow cygwin remaps
Sometimes DLLs over which cygwin has no control get mapped into cygwin
processes at locations that cygwin has chosen for its libraries.
This has been seen primarily with anti-virus DLLs. When this occurs,
cygwin must be instructed during the rebase to avoid the area of
memory where that DLL is mapped.
Background
Some background for this is available on
http://www.dont-panic.cc/capi/2007/10/29/git-svn-fails-with-fatal-error-unable-to-remap/
Because of unix fork semantics (presumably), cygwin libraries must be
mapped in the same location in both parent and child of a fork. All
cygwin libraries have hints in them as to where they should be mapped
in a processes address space; if those hints are followed, each
library will be mapped in the same location in both address spaces.
However, Windows is perfectly happy mapping a DLL anywhere in the
address space; the hint is not considered controlling. The remapping
error occurs when a cygwin process starts and one of its libraries
cannot be mapped to the location specified by its hint.
/usr/bin/rebaseall changes the DLL hints for all of the cygwin
libraries so that there are no inter-library conflicts; it does this
by choosing a contiguous but not overlapping library layout starting
at a base address and working down. This process makes sure there are
no intra-cygwin conflicts, but cannot deal with conflicts with
external DLLs that are in cygwin process address spaces
(e.g. anti-virus DLLs).
To handle this case, you need to figure out what the problematic
non-cygwin library is, where it is in the address space, and do the
rebase all so that no cygwin hints map libraries to that location.
Details
Download the ListDLLs executable from
sysinternals
Run it as administrator while some cygwin commands are running.
Scan the output for the cygwin process (identifiable by the command) and for
DLLs in that process that do not look like cygwin DLLs (like an AV). Note
the location of those libraries (there will usually only be the one).
Pick an address space location lower than its starting address.
Quit all cygwin processes.
Run a windows command shell as administrator
cd in \cygwin\bin
Run ash /usr/bin/rebaseall -b <base address> (This command can also take a
-v flag if you want to see the DLL layout.)
That should fix the problem.
Failed rebaseall
If you pick a base address that is too low, you may end up with a broken cygwin
install. You can reinstall it by running cygwin's setup.exe again, and on the
package selection page, clicking the "All" entry to Reinstall. You may have to
do this twice, as you may get errors on the first reinstall pass.
I have Administrator access to my PC. For me the solution to this was to run the Cygwin session as Administrator -- right the icon, run as administrator, as shown here:
After running as Administrator the first time, new Cygwin sessions started up without hassle.
There is a rebase utility that triggers the rebase as post-setup phase.
From dash or bash:
/usr/bin/rebase-trigger full
close all process and run again setup-x86_64.exe.
uninstall it,
and install the software for 32-bit.
I restarted 3 times, and then it was fine. wtf Windows 7
This exact same error message has various causes, not all of them related to setup-x86_64.exe, although I have seen it in that context as well. But if rebaseall didn't fix your problem, here's a suggestion that might work.
In the case I saw this morning, it turned out to have been caused by having a couple of processes that continued to run after I exited the mintty terminal emulator. My hunch is that these zombie processes prevent the console from being recycled. In my case, the two processes were determined experimentally, by reviewing a list of running processes for stray processes that are no longer needed. I found the two processes that were blocking me by reviewing the list of running tasks.
C:\WINDOWS\system32>tasklist | grep Console
CobraWinLDTP.exe 31844 Console 1 43,600 K
geckodriver.exe 52640 Console 1 32,164 K
C:\WINDOWS\system32>taskkill /F /PID 31844
SUCCESS: The process with PID 31844 has been terminated.
C:\WINDOWS\system32>taskkill /F /PID 52640
SUCCESS: The process with PID 52640 has been terminated.
I saw on some other stackoverflow questions that git is often the zombie process that causes this symptom (for some users). Unfortunately, any residual process that survives after your console session is closed can cause this problem, so you have to experiment.
Go to The Task manager
Kill 'Git for Windows' process
Reopen your git bash
It seems that all is working fine.
NOTE: In case you don't find 'Git for Windows' process and still have to face the same just kill 'Node.js: Server-side JavaScript' process instead
If you have turned Force randomization for images (Mandatory ASLR) on in Exploit protection of Windows Security, then you can turn it off by selecting Use default (Off) to address this issue.
My instance of this problem was also related to having turned on 'force randomization for images' in the Windows Security exploit protection settings.
After you change the setting back to the default off position and reset, you will have to run Git as an administrator in order to effect directory changes which apparently require elevated permission.
I wasn't able to determine a way to allow that setting to be turned on and not get this issue with Git though I played around with it for a while unsuccessfully.
Turning even optional security features off to get a single program working seems like a last resort option to me. However, this isn't just any program either.
I need to access some source code stored on SourceForge using CVS.
I used (many computers ago) to use WinCVS, so I downloaded it from SourceForge and installed it on this machine, which runs Windows XP 64-bit (latest SP).
However, during the second part of the install, when it tries to install CVSNT, the install asks all the usual questions, and hangs during the actual install.
I have traced the install using ProcMon, and the installer starts up, creates a temporary file in my temp directory (which is on drive E:), and then executes it.
I can't see any particular reason why the install hangs - there is no obvious loop. Both the original installer, and the temporary file create 2 threads, and one thread exits. So I guess the other thread is waiting for something which never happens.
Any idea how to proceed from here?
The issue is that the installer doesn't like the default installation path of c:\Program files (x86)\cvsnt — if you use c:\cvsnt the installer will proceed.
Update: this appears correct. If you still would like it in the default location under C:\Program Files (x86)..., use the 8.3 name (you can find it with dir /x), usually C:\PROGRA~2. As you can see in the screenshot, the last step appears correctly now. With a path with a space in it, it would hang forever.
Second part of wincvs --> cvsnt.exe get hangs with windows 7 due to incompatible, So you may try tortoiseCVS. It has the portable version and also working fine
SOLUTION FOR Windows 8 64-bit:
On Windows 8 64-bit I was unable to install CVSNT (even to c:\cvsnt), but I solved the problem by simple copy the whole CVTNT directory from my old pc.
I copied to C:\Program Files (x86)\cvsnt (exact location where wincvs expected to find cvsnt).
We had a similar problem on a machine at work (the difference being it was Windows 7 64-bit in our case). Even though the user had admin privileges, we were only able to resolve the issue by logging on directly as the admin before installing cvsnt.
Do not install the version of CVSNT that comes with WinCVS. It's an old, outdated, buggy version. Install a later release (at least 2.5.0.4).
All,
Am trying to get Node.js to work on Vista machine.
I installed Cygwin (as per the Github instructions) which appears to have been installed correctly. However, none of the commands are executing.
Are there any tutorials for the stages after the Cygwin installation?
PROBLEM: When any command is executed, I get 'Bash: command not found' error.
Not even command like 'c:\cygwin\bin' is executing.
When I type 'user' in cygwin command prompt, I get 'ntvdm has encountered an system error. Parameter incorrect'.
I thought the above error may be due to the firewall, disabling the firewall did not have any effect, running the program with admin rights also did not change the results...
Am confused and would love to get some guidance on what steps to go with next on getting Node.js up and running on a Windows Vista machine.
Many thanks,
UPDATE1:
We managed to make a bit more progress. It appears that we had not installed all the relevant files related to Cygwin. Upon re-download and reinstalled, it ran well, however, we have driven into another error. Error we get:
How to compile/install node.js(could not configure a cxx compiler!) (Ubuntu).
We followed the instructions as per the above thread (3rd post from top for Windows machines), however, we are still stuck at the same error.
Any guidance please?
Have you tried just using the Windows self contained binaries? http://node-js.prcn.co.cc/ This way you actually don't need to bother with Cygwin.
At first, i tried it your way too, using Cygwin. After smashing my head for the 10th time against a wall i just stopped trying and found a much cleaner solution.
I'm using VirtualBox running a Debain guest system to locally develop on my Windows 7 machine. Using VirtualBox, you can easily set up shared folders or port forwarding for node apps between your Windows machine and your Debian guest system.
Since you are using a plain Linux-system, all the compiling-pain is blown away.
If you plan to run node.js in production on a windows system: don't. I hardly believe node.js will be ever stable enough on windows-based systems using MINGW/Cygwin...
People seem to run into problems with Cygwin because they think that they are using a Windows machine.
If you install Cygwin, and open a bash shell prompt using the Cygwin icon, you are now in a UNIX environment and everything works the same as it would on UNIX. That includes building node.js.
I think you added some info to the question and I can see your problem. Yes, normally on Cygwin it has been possible to build node.js just as you would on any UNIX system, but that is no longer possible on Windows 7. Before running ./configure you have to:
Close all cygwin apps.
Double-click on C:\Cygwin\bin\ash.exe
Run ./rebaseall and when it completes, run ./perlrebase.
exit from the ash shell window.
At this point Cygwin will be back to normal and you can ./configure and make install.