On Mar 22 17:53, Ken Brown wrote:
In case it's relevant, my system is 64-bit Windows 7, with the most
recent cygwin snapshot:
It is relevant, but it has nothing to do with Windows 7. Actually, the
autoconf mmap test is testing a scenario which does not work on 64 bit
Windows systems. Here's what happens in a nutshell.
The actual pagesize on Windows is 4K. But there's something called
"allocation granularity" which is 64K. If you request virtual memory on
Windows, the memory address is always aligned to the allocation
granularity boundary. Even if you request 4K chunks, they are 64K
If you mmap anonymous memory, this is no big problem. Cygwin always
requests memory in 64K chunks since Cygwin's pagesize is set to 64K.
However, if you mmap a file, there's a problem. The mapping always
starts on a 64K boundary, but it end on the next 4K boundary beyond EOF.
So, for a file of size 1 byte, the memory section will be 4K. The other
60K following in the virtual address space are lost. And they are not
allocated. And i you try to access them you get a SEGV.
Fortunately, Cygwin uses the native NT calls in mmap. The native calls
support a flag called AT_ROUND_TO_PAGE, which allows to allocate memory
on a 4K boundary. So what Cygwin does is to mmap the file, and then to
request virtual memory rounded to the next 4K page to fill the rest of
the 64K allocation area. Now we have the full 64K allocated.
Unfortunately this doesn't work on 64 bit Windows. The reason is that
the WOW64 layer does not support the AT_ROUND_TO_PAGE flag. If you try
to use it, the OS call returns STTAUS_INVALID_PARAMETER. So you can't
allocate the remainder of the 64K allocation slot at all.
Back to the autoconf mmap test. What it does is to mmap a file of size
1 byte. Then it tests each byte in the mapped page. And since the
pagesize in Cygwin is 64K it tests all of 64K.
Given the above description, you can now imagine this works fine on 32
bit Windows, but it crashes on 64 bit Windows.