From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19693 invoked by alias); 13 May 2008 03:53:41 -0000 Received: (qmail 19403 invoked by uid 48); 13 May 2008 03:52:55 -0000 Date: Tue, 13 May 2008 03:53:00 -0000 Message-ID: <20080513035255.19402.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/36218] [4.4 regression] libgcj causes stack overflow in jc1.exe In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dannysmith at users dot sourceforge dot net" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-05/txt/msg01000.txt.bz2 ------- Comment #2 from dannysmith at users dot sourceforge dot net 2008-05-13 03:52 ------- (In reply to comment #0) > What negative consequences does increasing the default [stack] > allocation have? Minimal really, for a single threaded program like jc1.exe. We are just reserving address space not actual memory. In a multithreaded app, each thread reserves the same amount of address space as the primary thread (by default, but the default can be overiden), so too high a stack reserve for main thread can limit what is available for others. Is it possible to adjust this limit at runtime, perhaps as > needed? > No, not for main thread. It is built into the program header on MS windows. GNAT also bumps stack reserve to 32 MB for "non-tasking" apps. See system-mingw.ads. In old days, 32 MB was default for win32 in gnu ld. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218