Bug 3163 - [3.3 Only] gcc/aclocal.m4 mmap test fails on UnixWare 7.1.1
Summary: [3.3 Only] gcc/aclocal.m4 mmap test fails on UnixWare 7.1.1
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 3.3
: P1 normal
Target Milestone: 3.3.1
Assignee: Zack Weinberg
URL:
Keywords:
: 8365 10284 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-06-13 04:46 UTC by john
Modified: 2005-02-09 02:18 UTC (History)
8 users (show)

See Also:
Host: i586-sco-sysv5uw7.1.1
Target: i586-sco-sysv5uw7.1.1
Build: i586-sco-sysv5uw7.1.1
Known to work:
Known to fail:
Last reconfirmed: 2003-06-02 03:07:28


Attachments
3163-3.3.diff (4.54 KB, text/plain)
2003-06-26 01:01 UTC, Zack Weinberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description john 2001-06-13 04:46:05 UTC
	To quote gcc/aclocal.m4:

/* 3. If we map two adjacent 1-page regions and unmap them both with
   one munmap, both must go away.

   Getting two adjacent 1-page regions with two mmap calls is slightly
   tricky.  All OS's tested skip over already-allocated blocks; therefore
   we have been careful to unmap all allocated regions in previous tests.
   HP/UX allocates pages backward in memory.  No OS has yet been observed
   to be so perverse as to leave unmapped space between consecutive calls
   to mmap.  */

Well, UnixWare 7.1.1 is that perverse system.  It seems to leave
one page between each mapping.

Release:
3.0 20010611 (prerelease)

Environment:
System: UnixWare oceanic 5 7.1.1 i386 x86at SCO UNIX_SVR5


	
host: i586-sco-sysv5uw7.1.1
build: i586-sco-sysv5uw7.1.1
target: i586-sco-sysv5uw7.1.1
configured with: ../gcc-3.0-20010611/configure --prefix=/u/local --with-local_prefix=/u/local

How-To-Repeat:
	configure
Comment 1 robertlipe 2001-06-13 11:45:25 UTC
From: Robert Lipe <robertlipe@usa.net>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, john@Calva.COM,
        gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: bootstrap/3163
Date: Wed, 13 Jun 2001 11:45:25 -0500

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3163&database=gcc
 
                HP/UX allocates pages backward in memory. No OS has yet
 been
                observed
                to be so perverse as to leave unmapped space between
                consecutive calls
                to mmap. */
 
                Well, UnixWare 7.1.1 is that perverse system. It seems to
                leave
                one page between each mapping.
 
 This is actually documented behaviour.   From the mmap man page:
 
    References to pages in a mapped region which are beyond the
    page containing the end of a file will result in the delivery of a
    SIGBUS signal.
 
 It sounds like this test is looking for several undocumented 
 characteristics of mmap that just happen to be true on some systems
 and not a general case mmap.  Since the code provides a reasonable
 fallback, does this cause an actual problem or is it an observation
 that this test is failing becuase the OS doesn't satisfy the 
 characteristics wanted by this test?

Comment 2 Zack Weinberg 2001-06-13 20:33:38 UTC
From: "Zack Weinberg" <zackw@stanford.edu>
To: Robert Lipe <robertlipe@usa.net>
Cc: gcc-gnats@gcc.gnu.org, john@Calva.COM
Subject: Re: bootstrap/3163
Date: Wed, 13 Jun 2001 20:33:38 -0700

 On Wed, Jun 13, 2001 at 11:45:25AM -0500, Robert Lipe wrote:
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3163&database=gcc
 > 
 >                HP/UX allocates pages backward in memory. No OS has yet
 > been
 >                observed
 >                to be so perverse as to leave unmapped space between
 >                consecutive calls
 >                to mmap. */
 > 
 >                Well, UnixWare 7.1.1 is that perverse system. It seems to
 >                leave
 >                one page between each mapping.
 > 
 > This is actually documented behaviour.   From the mmap man page:
 > 
 >    References to pages in a mapped region which are beyond the
 >    page containing the end of a file will result in the delivery of a
 >    SIGBUS signal.
 
 That sentence is in everybody's mmap(2), but not everybody's mmap
 leaves one page between each successive anonymous mapping.
 
 The test is, however, too picky.  I originally wrote it to exercise
 every last detail of a Cygwin runtime bug.  I've seen problem reports
 go by for it on Solaris 8 and the Hurd as well as UnixWare 7.1.1.
 Fixing it just hasn't been very high on my list.
 
 It would probably be better to check for the buggy versions of Cygwin
 instead.  I don't know how to do that reliably, or which version is
 the earliest in which the bug was fixed.
 
 See thread at http://gcc.gnu.org/ml/gcc-bugs/2000-11/msg00588.html.
 
 -- 
 zw            I now propose to do a little a priorizing of my own.
               	-- Jerry Fodor, _The Mind Doesn't Work That Way_

Comment 3 john 2001-06-14 09:28:32 UTC
From: "John Hughes" <john@Calva.COM>
To: "Robert Lipe" <robertlipe@usa.net>, <gcc-gnats@gcc.gnu.org>,
   <gcc-prs@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>
Cc:  
Subject: RE: bootstrap/3163
Date: Thu, 14 Jun 2001 09:28:32 +0200

 >> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3163&database=gcc
 >> No OS has yet been observed to be so perverse as to leave unmapped
 >> space between consecutive calls to mmap. */
 >>
 >> Well, UnixWare 7.1.1 is that perverse system. It seems to leave
 >> one page between each mapping.
 
 > This is actually documented behaviour.   From the mmap man page:
 >
 >   References to pages in a mapped region which are beyond the
 >   page containing the end of a file will result in the delivery of a
 >   SIGBUS signal.
 
 No, that paragraph says that if I mmap 10 pages from a 5 page file
 access to the 5 pages beyond eof get a SIGBUS (note: not SIGSEGV).
 
 It says nothing about memory OUTSIDE the mmaped region.
 

Comment 4 Craig Rodrigues 2002-02-23 21:56:20 UTC
From: Craig Rodrigues <rodrigc@attbi.com>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, john@Calva.COM,
   gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: bootstrap/3163: gcc/aclocal.m4 mmap test fails on UnixWare 7.1.1
Date: Sat, 23 Feb 2002 21:56:20 -0500

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3163
 
 
 john@calva.com posted this info  in PR 3162:
 
 libiberty/aclocal.m4 has a check to see if strncmp runs off the
 end of the string.  It incorrectly fails on systems where
 MAP_ANON(YMOUS) must be used without an open fd, for example
  UnixWare 7.1.1.
 
 --- libiberty/aclocal.m4.orig   Wed Nov 22 09:32:26 2000
 +++ libiberty/aclocal.m4        Wed Jun 13 12:48:35 2001
 @@ -21,8 +21,6 @@
  #ifndef MAP_ANON
  #ifdef MAP_ANONYMOUS
  #define MAP_ANON MAP_ANONYMOUS
 -#else
 -#define MAP_ANON MAP_FILE
  #endif
  #endif
  
 @@ -39,6 +37,10 @@
  {
  #if defined(HAVE_MMAP) || defined(HAVE_MMAP_ANYWHERE)
    char *p;
 +#ifdef MAP_ANON
 +  p = (char *) mmap (0, MAP_LEN, PROT_READ|PROT_WRITE,
 +                    MAP_ANON|MAP_PRIVATE, -1, 0);
 +#else
    int dev_zero;
  
    dev_zero = open ("/dev/zero", O_RDONLY);
 @@ -46,7 +48,8 @@
      exit (1);
   
    p = (char *) mmap (0, MAP_LEN, PROT_READ|PROT_WRITE,
 -                    MAP_ANON|MAP_PRIVATE, dev_zero, 0);
 +                    MAP_FILE|MAP_PRIVATE, dev_zero, 0);
 +#endif
    if (p == (char *)-1)
      exit (2);
    else
 
 
 

Comment 5 Dara Hazeghi 2003-05-09 01:19:29 UTC
From: Dara Hazeghi <dhazeghi@yahoo.com>
To: gcc-gnats@gcc.gnu.org, john@Calva.COM
Cc:  
Subject: Re: bootstrap/3163: gcc/aclocal.m4 mmap test fails on UnixWare 7.1.1
Date: Fri, 9 May 2003 01:19:29 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=3163
 
 Hello,
 
 there have been no updates about this bug for over a year. Is this bug  
 reported still an issue on this platform with current releases of gcc?  
 Thanks,
 
 Dara
 
Comment 6 Wolfgang Bangerth 2003-05-09 15:21:42 UTC
State-Changed-From-To: open->feedback
State-Changed-Why: See Dara's question
Comment 7 Zack Weinberg 2003-06-02 03:06:26 UTC
I cannot say for sure whether or not this problem is still observable under
UnixWare 7.1.1 but we have several other reports of similar problems (bug 8365,
bug 10284) so I think it's still a concern.
Comment 8 Zack Weinberg 2003-06-02 03:07:53 UTC
*** Bug 8365 has been marked as a duplicate of this bug. ***
Comment 9 Zack Weinberg 2003-06-02 03:08:21 UTC
*** Bug 10284 has been marked as a duplicate of this bug. ***
Comment 10 Zack Weinberg 2003-06-04 22:25:16 UTC
I have checked in a patch for this bug in mainline:

	PR bootstrap/3163
	* aclocal.m4 (AC_FUNC_MMAP_ANYWHERE, AC_FUNC_MMAP_FILE): Delete.
	(gcc_AC_FUNC_MMAP_BLACKLIST): New.
	* configure.in: Check for sys/mman.h and mmap in AC_CHECK_HEADERS
	and AC_CHECK_FUNCS lists, respectively.  Use
	gcc_AC_FUNC_MMAP_BLACKLIST, not AC_FUNC_MMAP_ANYWHERE nor
	AC_FUNC_MMAP_FILE.
	* configure, config.in: Regenerate.

It may be worthwhile to check this onto the 3.3 release branch as well but I'm
not sure; in any case a bit more testing first is probably a good idea.
Comment 11 H.J. Lu 2003-06-23 15:28:33 UTC
I got:

test 3 nonconsecutive pages - 2000000000044000, 20000000002b8000

on ia64 Linux kernel from Red Hat and

checking for working mmap from /dev/zero... no
checking for working mmap with MAP_ANON(YMOUS)... no

As the result, I had

/* #undef HAVE_MMAP_DEV_ZERO */
/* #undef HAVE_MMAP_ANON */
#define HAVE_MMAP_FILE 1

in auto-host.h. Then I got bootstrap comparison failure.
Could someone please move this patch to 3.3 branch?
Comment 12 Zack Weinberg 2003-06-26 00:16:44 UTC
patch checked into 3.3 branch, audit trail should catch up eventually.
Comment 13 Zack Weinberg 2003-06-26 01:01:22 UTC
Subject:  Backport to 3.3


This was nice and easy to backport to 3.3 -- the only substantive
change was use of fatal_io_error instead of internal_error with %m.

zw

Comment 14 Zack Weinberg 2003-06-26 01:01:23 UTC
Created attachment 4285 [details]
3163-3.3.diff
Comment 15 CVS Commits 2003-06-26 01:01:37 UTC
Subject: Bug 3163

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	zack@gcc.gnu.org	2003-06-25 23:14:58

Modified files:
	gcc            : ChangeLog aclocal.m4 config.in configure 
	                 configure.in ggc-page.c 

Log message:
	PR bootstrap/3163
	* aclocal.m4 (AC_FUNC_MMAP_ANYWHERE, AC_FUNC_MMAP_FILE): Delete.
	(gcc_AC_FUNC_MMAP_BLACKLIST): New.
	* configure.in: Check for sys/mman.h and mmap in AC_CHECK_HEADERS
	and AC_CHECK_FUNCS lists, respectively.  Use
	gcc_AC_FUNC_MMAP_BLACKLIST, not AC_FUNC_MMAP_ANYWHERE nor
	AC_FUNC_MMAP_FILE.
	* configure, config.in: Regenerate.
	
	* ggc-page.c (init_gcc): Call fatal_io_error, not abort,
	if opening /dev/zero fails.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.619&r2=1.16114.2.620
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/aclocal.m4.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.61.2.1&r2=1.61.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config.in.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.146.2.3&r2=1.146.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/configure.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.641.2.13&r2=1.641.2.14
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/configure.in.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.627.2.12&r2=1.627.2.13
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ggc-page.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.57.2.3&r2=1.57.2.4