Is anyone able to build on Win 7 (original) (raw)

Volker Simonis volker.simonis at gmail.com
Tue Feb 14 11:29:52 UTC 2012

Hi Kelly,

that's an interesting hint. I looked at it and tried to understand what's behind it. Here's what I found out - if I'm wrong or if somebody has additional information I would appreciate any correction!

  1. Windows DLLs have a base address which indicates the virtual base address where they would like to get loaded to.

  2. If this address is already in use, the operating system chooses another base address and the DLL is relocated to that new base address. Relocation should be no problem for a DLL, but apparently the implementation of "fork()" in Cygwin is very picky about these base addresses and "..needs to have a very special memory layout to implement the fork semantics in Win32. If this memory layout is disrupted, fork breaks.." (from http://www.cygwin.com/ml/cygwin/2009-05/msg00413.html).

  3. The McAffe knowledge base entry cited by Kelly states: "..When a Cygwin DLL fails to load to the default address, Windows arbitrarily chooses an available address and loads it there. That works only as long as Windows chooses the same address every time, but there are a lot of conditions during startup that may affect the outcome."

  4. Cygwin comes with its own rebase tool (/bin/rebaseall) which "..does its best to locate all Cygwin DLLs that it knows of into a layout that avoids collisions.." "rebaseall" is usually called by setup.exe so if you do not manually install any DLLs, this shouldn't be a problem. I indeed ran 'rebaseall' (call 'rebaseall --help' for an instruction how to use it) without any positive effect and I assume this is because all the DLLs already had non-overlapping base addresses. There's one thing to keep in mind however: Cygwins 'rebaseall' can not rebase 'cygwin1.dll' because it is linked against it. To rebase 'cygwin1.dll' one has to use another rebase tool (e.g. "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\ReBase.Exe" from the MS SDK). I've done that but that even worsened things (probably because it is not so easy to rebase cygwin1.dll to a meaningful new base address without knowing the memory layout of 32-bit Windows processes:).

  5. During all these experiments I ran across another new Windows7 feature called ASLR (Address Space Layout Randomization, see http://en.wikipedia.org/wiki/Address_space_layout_randomization). Actually it is not really new in Windows 7 but from what I've read it is implemented much more aggressively in Windows 7. On Windows 7, ASLR can only be disabled by using the Enhanced Mitigation Experience Toolkit provided by Microsoft (http://support.microsoft.com/kb/2458544), (the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages registry setting has no effect in Windows 7)

  6. The default setting for ASLR is still "application opt in" which means that only applications which want will be randomized. You can check this for example with the Cygwins /usr/bin/peflags tool. It will display something like "[-dynamicbase]" for applications which don't want to be randomized. Now all Cygwin DLL's have "-dynamicbase", so why should this be a problem? My naive explanation is that the Cygwin DLLs still depend an native Windows runtime DLLs and they all will be randomized by default. If now one of these Windows sysytem DLLs will be placed at the default base address of a Cygwin DLL, the Cygwin DLL will have to be relocated with the outcome described in 2.

  7. I switched ASLR off (you need to reboot afterwards) and was able to do 4 consecutive, full builds without any error. After that I switched ASLR on again, rebooted and the second build failed with the well known "fork" problem.

To cut a long story short:

I would be graceful if anybody could confirm these findings or can come up with another, better solution/explanation.

Regards, Volker

On Thu, Feb 9, 2012 at 9:42 PM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:

Does this article provide any help: https://kc.mcafee.com/corporate/index?page=content&id=KB55075&actp=search&viewlocale=enUS&searchid=1328818133782 It suggests that rebase'ing the CYGWIN DLL's will help. Seems a bit strange to me, just passing it on. -kto On Jan 25, 2012, at 5:10 PM, Pete Brunet wrote:

I just had success with the following changes: - downgraded from cygwin 1.7.9 (with bash 4.1.10) to 1.7.0 (with bash 3.2.49) - changed ...\jdk\make\docs\Makefile line 74

ifeq ($(ARCHDATAMODEL),64)  MAXVMMEMORY = 1024 else  MAXVMMEMORY = 1024 <--- This was 512 endif I've only done one build and in prior builds had other issues besides the memory problem, i.e. fork and error 126, but there's always hope. If others could report their W7 configurations and whether or not there were problems, that would be helpful. Pete On 1/25/12 6:17 PM, Kelly O'Hair wrote: Sorry guys, I don't have the time or priority to track this down. Official builds are still happening on Windows XP and Windows 2003 X64 and these problems are not being seen on those systems.... yet... although we recently have been visited by the McAfee plague so maybe it's just a matter of time. ;^(

Someone with some strong Windows experience needs to run this to ground. We do need this to work, eventually. -kto On Jan 25, 2012, at 9:09 AM, Pete Brunet wrote:

I started W7 in safe mode and the build failed with a fork failure.  I think that eliminates things in the BLODA list.  If anyone out there is building OK on W7 please send your configuration, e.g. as shown below. Maybe that will suggest a different version of cygwin or bash.  -Pete

On 1/25/12 9:55 AM, Pete Brunet wrote: Thanks Volker, I was thinking I'm going to have to try using XP in a VM.  My W7 config is very close to yours (make 3.81 instead of 3.82).

W7 Pro, 64 bit, SP1 Intel Core 2 Duo, P8700, 2.53 GHz, 8 GB RAM CYGWINNT-6.1-WOW64 Bevo 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin GNU bash, version 4.1.10(4)-release (i686-pc-cygwin) GNU Make 3.81 Pete On 1/25/12 9:06 AM, Volker Simonis wrote: Hi Peter,

glad to see that other have the same problems:) But seriously, on Windows 7 I'm currently experiencing the same massive build problems and I'm not sure what the root cause of these problems is. I found the following bug which exactly describes the problems I'm facing: http://bugs.sun.com/bugdatabase/viewbug.do?bugid=6903517 Among others, these are: - rm: cannot remove directory `META-INF': Directory not empty - error:  cannot create example2.html: Permission denied - [javac] C:\Software\OpenJDK\jdk8\langtools\src\share\classes\com\sun\tools\javac\util\SharedNameTable.java:40: error: error while writing SharedNameTable: c:\Software\OpenJDK\outputamd64\langtools\build\bootstrap\classes\com\sun\tools\javac\util\SharedNameTable.class (Access is denied) but I also saw the 'out of memory' and 'for' problems mentioned by you. The description of bug 6903517 references the "Big List of Dodgy Apps" (http://cygwin.com/faq/faq.using.html#faq.using.bloda). This is a list in the Cygwin FAQ which lists applications like Virus Scanners which can interfere with Cygwin in an unpredictable way. An indeed the Windows 7 box on which I observe the problems has some of them installed (e.g. McAffe {Agent, GTI Proxy Agent, Intrusion Prevention, VirusScan Enterprise, AntySpywaare Enterprise} to name just a few). On the other hand, on the same Windows 7 box I have a virtual machine running inside VirtualBox  with WindowsXP which has the same McAffe software installed and it is running without any problems. The OpenJDK build always succeeds in the virtual machine! So I'm not quite sure of this is: - a problem of some additional software which is running on my Windows 7 box and interferes with Cygwin - a general Windows7 problem - a problem of the specific Cygwin version I'm using - a problem of Cygwin running on 64-bit Windows 7 I'll try to further narrow down the problem, but of course any hints are highly welcome (unfortunately I can't easily get rid of the McAffe stuff without losing my job, so please don't advise this:) Regards, Volker PS: below you can find the exact versions of the software/hardware I'm using: 64-bit Windows 7, SP 1 Dual Core Intel i7, 8GB RAM Cygwin (output of uname -a): CYGWINNT-6.1-WOW64 WDFN00299915A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin bash 4.1.10(4)  // installed by Cygwin setup.exe make 3.82  // compiled by myself In the Virtual box VM I have the following system: 64-bit Windows XP Professional Version 2003 SP 2 Cygwin (output of uname -a): CYGWINNT-5.2-WOW64 WDFV00248216A 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin bash 4.1.10(4)  // installed by Cygwin setup.exe make 3.82  // compiled by myself

On Tue, Jan 24, 2012 at 5:52 PM, Pete Brunet <peter.brunet at oracle.com> wrote: Is anyone able to build on Win 7?  I'm on my 8th build hoping to get to the end and have seen these errors: out of memory, 3 times - I have more than enough memory fork: Resource temporarily unavailable, 3 times error 126, once I have read http://cygwin.com/faq-nochunks.html#faq.using.bloda so apparently something on my system is causing a problem but I haven't been successful in finding it yet.  I have my Norton 360 "Auto-Protect" turned off.  It would be helpful to know if anyone has successfully built on Win 7 and also if anyone has ideas on what I might look for beyond what is listed in the cygwin FAQ. Thanks, Pete

More information about the build-dev mailing list