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

[Pavel Machek <pavel at suse dot cz>]

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.