This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Broken autoconf mmap test

On 3/23/2011 5:19 AM, Corinna Vinschen wrote:
On Mar 22 17:53, Ken Brown wrote:
On 3/22/2011 4:59 PM, Eric Blake wrote:
On 03/20/2011 02:51 PM, Ken Brown wrote:
What's the status of the broken autoconf mmap test, which always fails
on Cygwin even though Cygwin has a working mmap?

Autoconf 2.65 and newer do not have the bug. But packages still exist where configure was generated with< 2.65, so these packages still have the bug unless you either rerun newer autoconf, or pre-seed the cache.

Was this ever resolved? I see that cygport is still using the workaround

export ac_cv_func_mmap_fixed_mapped=yes

This workaround is still necessary, as long as there are still packages that don't run autoreconf and where configure was generated with a too-old autoconf.

I'm still seeing failures when building both emacs and texlive, even after autoreconf with the current (2.68) version installed. Attached is the relevant portion of config.log from an emacs build. This is a build of the current emacs trunk, after running 'autoreconf -I m4'. The same thing happens if I build emacs-23.3. If you want to try to reproduce it, here's the source:


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.

Thanks for the explanation, Corinna. I've reported this to the autoconf list.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]