From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-13107-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 20059 invoked by alias); 20 Dec 2001 18:36:00 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 20039 invoked by uid 71); 20 Dec 2001 18:36:00 -0000
Date: Thu, 20 Dec 2001 10:36:00 -0000
Message-ID: <20011220183600.20035.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Neil Booth <neil@daikokuya.demon.co.uk>
Subject: Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin
Reply-To: Neil Booth <neil@daikokuya.demon.co.uk>
X-SW-Source: 2001-12/txt/msg01015.txt.bz2
List-Id: <gcc-prs.sourceware.org>

The following reply was made to PR bootstrap/5149; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Werner Tuchan <tuwn@gmx.net>
Cc: neil@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin
Date: Thu, 20 Dec 2001 18:33:23 +0000

 Werner Tuchan wrote:-
 
 > Thats the piece of code that loaded the file, this time its libgcc2.c.
 > 
 > cppfiles.c
 >   388       /* Use mmap if the file is big enough to be worth it (controlled
 >   389   by MMAP_THRESHOLD) and if we can safely count on there being
 >   390   at least one readable NUL byte after the end of the file's
 >   391   contents.  This is true for all tested operating systems when
 >   392   the file size is not an exact multiple of the page size.  */
 > - 393       if (size / pagesize >= MMAP_THRESHOLD
 >   394    && (size % pagesize) != 0)
 >   395  {
 > - 396    buf = (U_CHAR *) mmap (0, size, PROT_READ, MAP_PRIVATE, inc->fd,
 > 0);
 > - 397    if (buf == (U_CHAR *)-1)
 >   398      goto perror_fail;
 > - 399    inc->mapped = 1;
 > - 400  }
 >   401       else
 >   402 #endif
 
 Cool, this is useful, thanks.
 
 > (gdb) x /s buf + 46170
 > 0x83a5445a:  "ED_ATEXIT */\n\n#endif /* L_exit */\n"
 > 
 > (gdb) x /100xb buf + 46170
 > 0x83a5445a: 0x45 0x44 0x5f 0x41 0x54 0x45 0x58 0x49
 > 0x83a54462: 0x54 0x20 0x2a 0x2f 0x0a 0x0a 0x23 0x65
 > 0x83a5446a: 0x6e 0x64 0x69 0x66 0x20 0x2f 0x2a 0x20
 > 0x83a54472: 0x4c 0x5f 0x65 0x78 0x69 0x74 0x20 0x2a
 > 0x83a5447a: 0x2f 0x0a 0xc0 0xc0 0xc0 0x00 0xc0 0xc0
 > 0x83a54482: 0xc0 0x00 0xc0 0xc0 0xc0 0x00 0xc0 0xc0
 > 0x83a5448a: 0xc0 0x00 0xc0 0xc0 0xc0 0x00 0xc0 0xc0
 > 0x83a54492: 0xc0 0x00 0xc0 0xc0 0xc0 0x00 0xc0 0xc0
 > 0x83a5449a: 0xc0 0x00 0x00 0x00 0x00 0x00 0x00 0x00
 > 0x83a544a2: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
 > 0x83a544aa: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
 > 0x83a544b2: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
 > 0x83a544ba: 0x00 0x00 0x00 0x00
 
 Weird.  The bytes after EOF are a mixture of NULs and 0xc0.  Is 0xc0
 of special significance in Windows?  Is your version of cygwin the
 latest?  I recall some talk about mmap bugs in cygwin.
 
 I guess that we have to disable mmap() on cygwin, or at least on
 specific versions.  Do you have any better ideas Zack?
 
 Neil.