other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit

other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit

[Matthias Klose]

>Number:         9081
>Category:       other
>Synopsis:       gcc doesn't diagnose, that the compiler exceeds a compiler limit
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          accepts-illegal
>Submitter-Id:   net
>Arrival-Date:   Sat Dec 28 06:06:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Pavel Machek <pavel@atrey.karlin.mff.cuni.cz>
>Release:        3.2.1 (Debian) (Debian unstable)
>Organization:
The Debian Project
>Environment:
System: Debian GNU/Linux (unstable)
Architecture: i686
host: i386-linux
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.2.2 20021212 (Debian prerelease)
>Description:
[ Reported to the Debian BTS as report #133574.
  Please CC 133574@bugs.debian.org on replies.
  Log of report can be found at http://bugs.debian.org/133574 ]
	

The following buggy code is exceeding a compiler limit,
thus the code behaves undefined. There is a bug in the compiler also:
the compiler should diagnose that you exceed the limit, but there is
no reasonable way you could expect this code to work on the
microprocessor you are using (and with the operating system you are
using).

#define MAXLEN 20
#define MAXTAG 10
double speedup[MAXLEN][MAXLEN][MAXLEN][MAXLEN][MAXTAG][MAXTAG][MAXTAG];

void
init_speedup(void)
{
    int i, j, k, l, o, m, n;
    for (i=0; i<MAXLEN; i++)
        for (j=0; j<MAXLEN; j++)
            for (k=0; k<MAXLEN; k++)
                for (l=0; l<MAXLEN; l++)
                    for (o=0; o<MAXTAG; o++)
                        for (m=0; m<MAXTAG; m++)
                            for (n=0; n<MAXTAG; n++)
                                speedup[i][j][k][l][o][m][n] = -1.0;
}

int main(void)
{
    init_speedup();
    return 0;
}
>How-To-Repeat:
	
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit

[Peter Bergner]

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

From: Peter Bergner <bergner@vnet.ibm.com>
To: 133574@bugs.debian.org, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, pavel@atrey.karlin.mff.cuni.cz
Cc:  
Subject: Re: other/9081: gcc doesn't diagnose, that the compiler exceeds a
 compiler limit
Date: Mon, 27 Jan 2003 20:39:29 -0600

 We hit this same bug on ppc64 running 32-bit apps with the following
 testcase (32-bit apps get a full 4G of addr space to live in on ppc64):
 
      char x[2000000000];
 
      int
      main(void)
      {
          return 10;
      }
 
 Pavel is correct that all the calls to do_brk fail to test
 the return status of do_brk.  This is only part of the problem.
 The other major problem is that we don't call set_brk to reserve
 the bss region for the application until after we've already loaded
 the loader via the load_elf_interp() call.
 
 I have a patch that fixes both of those problems, but got delayed
 in posting since I was also trying to clean up what looks to be
 memory leaks in the error paths of load_elf_binary() before getting
 pulled away on another problem.  For example, it would seem the
 following code should be freeing some of the storage it allocaed
 before returning.  I'll try and clean up my patch and submit it.
 
          /* Do this so that we can load the interpreter, if need be.  We will
             change some of these later */
          current->mm->rss = 0;
          retval = setup_arg_pages(bprm);
          if (retval < 0) {
                  send_sig(SIGKILL, current, 0);
                  return retval;
          }
 
 Peter
 
 

Re: other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit

[Pavel Machek]

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

From: Pavel Machek <pavel@suse.cz>
To: rth@gcc.gnu.org, 133574@bugs.debian.org, gcc-bugs@gcc.gnu.org,
	gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit
Date: Sun, 26 Jan 2003 21:02:51 +0100

 Hi!
 
 > Synopsis: gcc doesn't diagnose, that the compiler exceeds a compiler limit
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: rth
 > State-Changed-When: Sun Jan 26 09:39:58 2003
 > State-Changed-Why:
 >     This isn't a compiler problem.  There is no compiler limit that
 >     has been exceeded.  Indeed, the executable generated looks fine.
 >     The kernel, however, is refusing to map the very large bss
 >     segment.  Perhaps your ulimit is set too low?  Perhaps you
 >     don't have enough VM to satisfy the request?
 >     
 >     In fact, if I enable a 2G swap file, and link the program
 >     statically, then it runs just fine.
 >     
 >     (If you don't link statically, then ld.so crashes.  I suspect
 >     a different kernel bug, in that it's not adjusting where it
 >     maps ld.so based on the large bss segment.)
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9081
 
 It indeed is a kernel problem, see fs/binfmt_elf.c, where set_brk does
 not do any error checking *at all* :-(.
 									Pavel
 
 -- 
 Casualities in World Trade Center: ~3k dead inside the building,
 cryptography in U.S.A. and free speech in Czech Republic.

Re: other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit

[rth]

Synopsis: gcc doesn't diagnose, that the compiler exceeds a compiler limit

State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Sun Jan 26 09:39:58 2003
State-Changed-Why:
    This isn't a compiler problem.  There is no compiler limit that
    has been exceeded.  Indeed, the executable generated looks fine.
    The kernel, however, is refusing to map the very large bss
    segment.  Perhaps your ulimit is set too low?  Perhaps you
    don't have enough VM to satisfy the request?
    
    In fact, if I enable a 2G swap file, and link the program
    statically, then it runs just fine.
    
    (If you don't link statically, then ld.so crashes.  I suspect
    a different kernel bug, in that it's not adjusting where it
    maps ld.so based on the large bss segment.)

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