From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24171 invoked by alias); 29 Mar 2003 00:36:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 24152 invoked by uid 71); 29 Mar 2003 00:36:01 -0000 Resent-Date: 29 Mar 2003 00:36:01 -0000 Resent-Message-ID: <20030329003601.24150.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, Kevin Ryde Received: (qmail 23154 invoked from network); 29 Mar 2003 00:33:19 -0000 Received: from unknown (HELO snoopy.pacific.net.au) (61.8.0.36) by sources.redhat.com with SMTP; 29 Mar 2003 00:33:19 -0000 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) by snoopy.pacific.net.au (8.12.3/8.12.3/Debian-5) with ESMTP id h2T0XIRk022437 for ; Sat, 29 Mar 2003 11:33:18 +1100 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h2T0XHoJ025189 for ; Sat, 29 Mar 2003 11:33:17 +1100 (EST) Received: from localhost (ppp100.dyn228.pacific.net.au [203.143.228.100]) by wisma.pacific.net.au (8.12.8/8.12.8) with ESMTP id h2T0XEqn008265 for ; Sat, 29 Mar 2003 11:33:16 +1100 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 18z4H1-00079y-00; Sat, 29 Mar 2003 10:32:39 +1000 Message-Id: <87y92zqafy.fsf@zip.com.au> Date: Sat, 29 Mar 2003 00:56:00 -0000 From: Kevin Ryde To: gcc-gnats@gcc.gnu.org Subject: c/10260: alloca 0xFFFFFFFF and -fstack-check X-SW-Source: 2003-03/txt/msg02029.txt.bz2 List-Id: >Number: 10260 >Category: c >Synopsis: alloca 0xFFFFFFFF and -fstack-check >Confidential: no >Severity: non-critical >Priority: low >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Sat Mar 29 00:36:00 UTC 2003 >Closed-Date: >Last-Modified: >Originator: >Release: 3.2.1 20020830 (Debian prerelease) (Debian testing/unstable) >Organization: >Environment: System: Linux blah 2.2.15 #1 Tue Apr 25 17:13:48 EST 2000 i586 unknown Architecture: i586 host: i386-pc-linux-gnu build: i386-pc-linux-gnu target: i386-pc-linux-gnu configured with: /mnt/data/gcc-3.1/gcc-3.2-3.2.1ds0/src/configure -v --enable-languages=c,c++,java,f77,proto,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-java-gc=boehm --enable-objc-gc i386-linux >Description: When a program attempts to alloca 0xFFFFFFFF bytes under -fstack-check, a stack overflow exception is not provoked. >How-To-Repeat: The program foo.c below compiled and run gcc -fstack-check foo.c ./a.out successfully reaches and executes the printf, whereas I had hoped it would get a segv, which is what happens when a smaller alloca amount like 0xFFFF0000 is requested. Looking at the code generated I guess a size like 0xFFFFFFFF is rounded up to a multiple of the stack alignment, giving 0. And the 4392 byte safety margin makes sizes like 0xFFFFFF00 wrap around to smallish positive values too. In normal circumstances I wouldn't think this is a problem, since anyone asking for such sizes deserves everything they get, but when -fstack-check is in use I think it'd be highly desirable to ensure a system stack overflow is provoked for any size bigger than the system can handle. The same seems to be true of -fstack-limit-symbol (in the current gcc cvs), but only in respect of the rounding up, so 0xFFFFFFFF is not detected as an overflow, but sizes up to 0xFFFFFFF0 are. --=-=-= Content-Type: text/x-csrc Content-Disposition: attachment; filename=foo.c volatile unsigned n = 0xFFFFFFFF; int main (void) { char *p; p = __builtin_alloca (n); printf ("%p\n", p); } --=-=-=-- >Fix: >Release-Note: >Audit-Trail: >Unformatted: --=-=-=