From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18429 invoked by alias); 4 Nov 2006 22:07:35 -0000 Received: (qmail 18411 invoked by alias); 4 Nov 2006 22:07:35 -0000 Date: Sat, 04 Nov 2006 22:07:00 -0000 Message-ID: <20061104220735.18410.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "dave at hiauly1 dot hia dot nrc dot ca" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2006-q4/txt/msg00095.txt.bz2 List-Id: ------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-04 22:07 ------- Subject: Re: jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes > Except that all of these were fixed in the followup patch and a later > typo fix, *including* the memory usage (see honza's tester). I may have been wrong above as to which java compilation caused the build failure because make -j 4 was used. In any case, the compilation fails with the gnu-xml.list. The backtrace is shown below. Seems to indicate a problem with alias analysis. Breakpoint 1, xmalloc_failed (size=1073885996) at ../../gcc/libiberty/xmalloc.c:123 123 if (first_break != NULL) (gdb) bt #0 xmalloc_failed (size=1073885996) at ../../gcc/libiberty/xmalloc.c:123 #1 0x003da3ec in xmalloc (size=4072) at ../../gcc/libiberty/xmalloc.c:149 #2 0x003d8c0c in _obstack_newchunk (h=0x4002332c, length=2062413872) at ../../gcc/libiberty/obstack.c:253 #3 0x000b1ff4 in bitmap_elt_insert_after (head=0x42631088, elt=0x6a2c7e38, indx=426) at ../../gcc/gcc/bitmap.c:122 #4 0x000b215c in bitmap_ior_into (a=0x42631088, b=0x7aedf030) at ../../gcc/gcc/bitmap.c:1170 #5 0x0018d408 in set_union_with_increment (to=0x42631088, from=0x40ea8c40, inc=0) at ../../gcc/gcc/tree-ssa-structalias.c:715 #6 0x0019089c in solve_graph (graph=0x40044f28) at ../../gcc/gcc/tree-ssa-structalias.c:2084 #7 0x00191d48 in compute_points_to_sets (ai=0x40ea8c40) at ../../gcc/gcc/tree-ssa-structalias.c:4840 #8 0x001f2638 in compute_may_aliases () at ../../gcc/gcc/tree-ssa-alias.c:948 #9 0x00185e50 in execute_one_pass (pass=0x4000c158) at ../../gcc/gcc/passes.c:870 #10 0x00185fcc in execute_pass_list (pass=0x4000c158) at ../../gcc/gcc/passes.c:917 #11 0x00185fe0 in execute_pass_list (pass=0x40002b60) at ../../gcc/gcc/passes.c:918 #12 0x0008abc4 in tree_rest_of_compilation (fndecl=0x77b85c40) at ../../gcc/gcc/tree-optimize.c:463 #13 0x0005a1b4 in java_expand_body (fndecl=0xfe8) at ../../gcc/gcc/java/decl.c:2079 #14 0x001aa4ec in cgraph_expand_function (node=0x77b85cb0) at ../../gcc/gcc/cgraphunit.c:1241 #15 0x001abfb8 in cgraph_assemble_pending_functions () at ../../gcc/gcc/cgraphunit.c:374 #16 0x001aba9c in cgraph_finalize_function (decl=0x77b85c40, nested=0 '\0') at ../../gcc/gcc/cgraphunit.c:503 #17 0x001abee0 in cgraph_build_static_cdtor (which=73 'I', body=0x788fc978, priority=1113788552) at ../../gcc/gcc/cgraphunit.c:1727 #18 0x000789d8 in java_parse_file (set_yydebug=4072) at ../../gcc/gcc/java/jcf-parse.c:1065 #19 0x00166c6c in toplev_main (argc=1074028328, argv=0x0) at ../../gcc/gcc/toplev.c:1033 #20 0x0008741c in main (argc=4072, argv=0x7aedf030) at ../../gcc/gcc/main.c:35 When solve_graph is called the last time, the size of jc1 stands at about 321M. This jumps rapidly to 968M. Up to this point, the java library had been building without problems for a number of months. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29587