Peter O'Gorman wrote:
> As you can see from this little snippet of gcc configure, you can't mmap
> /dev/zero on darwin.
>
> AC_CACHE_CHECK([whether mmap from /dev/zero works],
> gcc_cv_func_mmap_dev_zero,
> [# Add a system to this blacklist if it has mmap() but /dev/zero
> # does not exist, or if mmapping /dev/zero does not give anonymous
> # zeroed pages with both the following properties:
> # 1. If you map N consecutive pages in with one call, and then
> # unmap any subset of those pages, the pages that were not
> # explicitly unmapped remain accessible.
> # 2. If you map two adjacent blocks of memory and then unmap them
> # both at once, they must both go away.
> # Systems known to be in this category are Windows (all variants),
> # VMS, and Darwin.
> case "$host_os" in
> vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
> gcc_cv_func_mmap_dev_zero=no ;;
> *)
> gcc_cv_func_mmap_dev_zero=yes;;
> esac])
But gnulib's pagealign_alloc is not doing case 1 and not doing case 2.
It calls mmap() on N pages at once, and then ultimately munmap() on the
same N pages at once.
Also, GNU clisp uses mmap() with more complicated cases than this, including
mprotect() and partial munmap()s, and it works fine on Darwin.
> I just tried to use cvs-1.12.12 on Mac OS X, and it always dies. I traced
> the problem to pagealign_alloc.c, which attempts to mmap /dev/zero.
How did you track that down to pagealign_alloc.c?
I'd rather guess that mmap() on MacOS X works fine but either
- pagealign_alloc.c has a bug, or
- CVS has some memory related bugs, and you don't happen to see them
when pagealign_alloc uses malloc() instead of mmap() - because of the
way malloc() internally does its bookkeeping.
Can you exclude these?
Bruno
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
