Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

[neil]

Synopsis: gcc-20011217 reads beyond EOF on cygwin

State-Changed-From-To: feedback->closed
State-Changed-By: neil
State-Changed-When: Wed Jun 19 04:23:38 2002
State-Changed-Why:
    I believe this is fixed.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5149

Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

[Zack Weinberg]

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

From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Werner Tuchan <tuwn@gmx.net>, 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: Fri, 21 Dec 2001 23:27:58 -0800

 On Thu, Dec 20, 2001 at 07:09:10PM +0000, Neil Booth wrote:
 > Zack Weinberg wrote:-
 > 
 > > No.  But the AC_FUNC_MMAP_FILE macro (gcc/aclocal.m4) already executes
 > > a test program to determine whether or not mmap works the way we want.
 > > It would be easy enough to add a check that byte (len+1) of its test
 > > file is a NUL.  [And we'd better not be looking at byte len+2, or
 > > we'll segfault if the file length is one less than a multiple of
 > > PAGE_SIZE.]
 > 
 > Looking at the dump Werner supplied, filled with 0xc0 and NULs, I fear
 > this could pass on cygwin by fluke.  Better just to blacklist it IMO.
 > HAVE_BROKEN_MMAP or something.
 
 Agreed.  Come to think of it, if we blacklist cygwin, I believe we can
 junk almost all of the mmap testing gook, both MMAP_FILE and
 MMAP_ANYWHERE.  (Best check the mailing lists for the origins of those
 tests, first, though.)
 
 zw

Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

[Neil Booth]

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>, neil@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
	gcc-gnats@gcc.gnu.org, cygwin@cygwin.com
Cc:  
Subject: Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin
Date: Fri, 21 Dec 2001 18:48:12 +0000

 Christopher Faylor wrote:-
 
 > Can I ask why we'd be reading beyond EOF?  Is it guaranteed that bytes beyond
 > EOF will be zero on UNIX?
 
 This was discussed in September (see thread in gcc@ entitled "Bumming
 cycles out of parse_identifier").  It was decided that all known
 current Unix implementations have zeros until the next page boundary.
 Assuming EOF is indicated by a NUL is used as a lexer optimization.
 
 Neil.

Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

[Christopher Faylor]

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

From: Christopher Faylor <cgf@redhat.com>
To: Werner Tuchan <tuwn@gmx.net>
Cc: Neil Booth <neil@daikokuya.demon.co.uk>, neil@gcc.gnu.org,
   gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, cygwin@cygwin.com
Subject: Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin
Date: Fri, 21 Dec 2001 12:20:07 -0500

 On Fri, Dec 21, 2001 at 03:42:14PM +0100, Werner Tuchan wrote:
 >> 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.
 >
 >The cygwin version is pretty recent. Two weeks old or so. The data after EOF
 >is only garbage. I've seen different values than 0x0 or 0xc0 in the error
 >messages. Windows propably doesn't clear the page before mapping the file
 >onto it. There is likely a different behaviour here between Windows ME and
 >NT.
 
 Can I ask why we'd be reading beyond EOF?  Is it guaranteed that bytes beyond
 EOF will be zero on UNIX?
 
 cgf

Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

[Werner Tuchan]

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

From: "Werner Tuchan" <tuwn@gmx.net>
To: "Neil Booth" <neil@daikokuya.demon.co.uk>
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: Fri, 21 Dec 2001 15:42:14 +0100

 >
 > 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.
 >
 
 The cygwin version is pretty recent. Two weeks old or so. The data after EOF
 is only garbage. I've seen different values than 0x0 or 0xc0 in the error
 messages. Windows propably doesn't clear the page before mapping the file
 onto it. There is likely a different behaviour here between Windows ME and
 NT.
 
 
 

Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

[Neil Booth]

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Werner Tuchan <tuwn@gmx.net>, 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 19:09:10 +0000

 Zack Weinberg wrote:-
 
 > No.  But the AC_FUNC_MMAP_FILE macro (gcc/aclocal.m4) already executes
 > a test program to determine whether or not mmap works the way we want.
 > It would be easy enough to add a check that byte (len+1) of its test
 > file is a NUL.  [And we'd better not be looking at byte len+2, or
 > we'll segfault if the file length is one less than a multiple of
 > PAGE_SIZE.]
 
 Looking at the dump Werner supplied, filled with 0xc0 and NULs, I fear
 this could pass on cygwin by fluke.  Better just to blacklist it IMO.
 HAVE_BROKEN_MMAP or something.
 
 Neil.

Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

[Zack Weinberg]

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

From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Werner Tuchan <tuwn@gmx.net>, 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 10:57:47 -0800

 On Thu, Dec 20, 2001 at 06:33:23PM +0000, Neil Booth wrote:
 > 
 > 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?
 
 No.  But the AC_FUNC_MMAP_FILE macro (gcc/aclocal.m4) already executes
 a test program to determine whether or not mmap works the way we want.
 It would be easy enough to add a check that byte (len+1) of its test
 file is a NUL.  [And we'd better not be looking at byte len+2, or
 we'll segfault if the file length is one less than a multiple of
 PAGE_SIZE.]
 
 zw

Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

[Neil Booth]

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.

Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

[Werner Tuchan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3028 bytes --]

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

From: "Werner Tuchan" <tuwn@gmx.net>
To: <neil@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>,
	<gcc-prs@gcc.gnu.org>,
	<nobody@gcc.gnu.org>,
	<tuwn@gmx.net>,
	<gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin
Date: Thu, 20 Dec 2001 15:45:32 +0100

 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
 
 
 (gdb) x inc.name
 0x10a3af8:  "../../gcc-20011217/gcc/libgcc2.c"
 
 (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
 
 
 -----Ursprüngliche Nachricht-----
 Von: <neil@gcc.gnu.org>
 An: <gcc-bugs@gcc.gnu.org>; <gcc-prs@gcc.gnu.org>; <nobody@gcc.gnu.org>;
 <tuwn@gmx.net>
 Gesendet: Donnerstag, 20. Dezember 2001 01:20
 Betreff: Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin
 
 
 > Synopsis: gcc-20011217 reads beyond EOF on cygwin
 >
 > State-Changed-From-To: open->feedback
 > State-Changed-By: neil
 > State-Changed-When: Wed Dec 19 16:20:04 2001
 > State-Changed-Why:
 >     Is there any chance you could try and debug this?
 >     I need to know which code path is being taken inside
 >     read_include_file() in cppfiles.c, when it is reading in
 >     the file(s) that cause the problem (e.g. longlong.h).
 >     In particular, we need to be sure that the in-memory
 >     file buffer is properly NUL-terminated.
 >
 >     If you use -v, you will see the command line used to invoke cc1; that
 is what you should try and debug.
 >
 >     Thanks.
 >
 >
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p
 r=5149
 >
 

Re: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

[neil]

Synopsis: gcc-20011217 reads beyond EOF on cygwin

State-Changed-From-To: open->feedback
State-Changed-By: neil
State-Changed-When: Wed Dec 19 16:20:04 2001
State-Changed-Why:
    Is there any chance you could try and debug this?
    I need to know which code path is being taken inside
    read_include_file() in cppfiles.c, when it is reading in
    the file(s) that cause the problem (e.g. longlong.h).
    In particular, we need to be sure that the in-memory
    file buffer is properly NUL-terminated.
    
    If you use -v, you will see the command line used to invoke cc1; that is what you should try and debug.
    
    Thanks.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5149

bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin

[tuwn]

>Number:         5149
>Category:       bootstrap
>Synopsis:       gcc-20011217 reads beyond EOF on cygwin
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 18 03:56:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Werner Tuchan
>Release:        gcc 3.1 20011217
>Organization:
>Environment:
Windows ME
1.3.6-cygwin 1-3-6-6
../gcc-20011217/configure --with-gcc-version-trigger=/home/gcc/gcc-20011217/gcc/version.c --host=i686-pc-cygwin
>Description:
I get the following error messages for diffent files on each retry. The linenumbers indicate that stale data after the end of the file is read. The souce files themselves are ok.
gcc 2.95.3-5 and gcc 3.0.2 do not show this problem.

/home/gcc/gcc/gcc/xgcc -B/home/gcc/gcc/gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -O2 -I../../gcc-20011217/gcc/../winsup/include -I../../gcc-20011217/gcc/../winsup/cygwin/include -I../../gcc-20011217/gcc/../winsup/w32api/include -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include   -g1  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../gcc-20011217/gcc -I../../gcc-20011217/gcc/. -I../../gcc-20011217/gcc/config -I../../gcc-20011217/gcc/../include  -DL_ashldi3 -c ../../gcc-20011217/gcc/libgcc2.c -o libgcc/./_ashldi3.o
In file included from ../../gcc-20011217/gcc/libgcc2.h:299,
                 from ../../gcc-20011217/gcc/libgcc2.c:46:
../../gcc-20011217/gcc/longlong.h:1489: stray '\7' in program
../../gcc-20011217/gcc/longlong.h:1489: stray '\210' in program
In file included from ../../gcc-20011217/gcc/libgcc2.h:299,
                 from ../../gcc-20011217/gcc/libgcc2.c:46:
../../gcc-20011217/gcc/longlong.h:1489:4: warning: null character(s) ignored
../../gcc-20011217/gcc/longlong.h:1489: parse error before "T"
../../gcc-20011217/gcc/longlong.h:1489: stray '\1' in program
../../gcc-20011217/gcc/longlong.h:1490:1: warning: null character(s) ignored
../../gcc-20011217/gcc/longlong.h:1490: stray '\200' in program
../../gcc-20011217/gcc/longlong.h:1490: stray '\240' in program
../../gcc-20011217/gcc/longlong.h:1490: stray '\261' in program
../../gcc-20011217/gcc/longlong.h:1490: stray '\214' in program
../../gcc-20011217/gcc/longlong.h:1490: stray '\261' in program
../../gcc-20011217/gcc/longlong.h:1490: stray '\305' in program
../../gcc-20011217/gcc/longlong.h:1490: stray '\276' in program
>How-To-Repeat:
Make a native build of gcc-20011217 on windows me / cygwin.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: