From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15364 invoked by alias); 5 Jul 2006 22:48:46 -0000 Received: (qmail 15264 invoked by uid 48); 5 Jul 2006 22:48:40 -0000 Date: Wed, 05 Jul 2006 22:48:00 -0000 Message-ID: <20060705224840.15263.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++ In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "pcarlini at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-07/txt/msg00378.txt.bz2 List-Id: ------- Comment #6 from pcarlini at suse dot de 2006-07-05 22:48 ------- (In reply to comment #5) > The threads point is just a basic stack size issue: threads on linux have a > fixed size which is often smaller than the main stack size limit. Ok then. > With an output width of 60 million, it's easy to see a failure, even on a main > stack. > > hollerith:~/exp-string-width$ ulimit -Ss > 8192 > hollerith:~/exp-string-width$ /home/mec/gcc-4.2-20060624/install/bin/g++ z1.cc > hollerith:~/exp-string-width$ a.out > /dev/null > Segmentation fault Note, in general, I guess we are often going to fail anyway (at least for some of the pointed out uses) only, throwing a bad_alloc exception instead of seg-faulting, I hope that is acceptable... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277