From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19871 invoked by alias); 12 May 2008 11:02:28 -0000 Received: (qmail 19135 invoked by uid 48); 12 May 2008 11:01:45 -0000 Date: Mon, 12 May 2008 11:02:00 -0000 Subject: [Bug libgcj/36218] New: [4.4 regression] libgcj causes stack overflow in jc1.exe X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "aaronavay62 at aaronwl dot com" 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/msg00916.txt.bz2 Several files in libgcj will cause jc1.exe to exhaust its stack space allocation. This can be worked around by compiling jc1.exe with -Wl,--stack,0x2000000, which can be accomplished by including it in LDFLAGS when compiling. (This exact size is arbitrary; it's big enough to work, but perhaps much too big.) The cause seems to be massive recursion between find_assert_locations() and find_conditional_asserts(). I'm not sure if this is intended behavior. If this is intended behavior, it's not clear to me what the right thing to do to fix this is. What negative consequences does increasing the default allocation have? Is it possible to adjust this limit at runtime, perhaps as needed? -- Summary: [4.4 regression] libgcj causes stack overflow in jc1.exe Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: build, memory-hog Severity: critical Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com GCC host triplet: i386-pc-mingw32 OtherBugsDependingO 36216 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218