A large lto1-wpa run with 20110603 results now in malloc.c:3551: munmap_chunk: Assertion `ret == 0' failed. on x86-64-linux. When I run with MALLOC_CHECK_=2 it seems to get a bit further, but eventually aborts (and deadlocks because the abort->internal_error handler calls malloc again) Here's the original trace for the malloc that aborts (with MALLOC_CHECK_=2) Any suggestions for patches to try to revert? Note full bisect is difficult because this run depends on some earlier fixes. Not uploading a test case currently because it's quite large. #10 0x00002b236701d4e5 in raise () from /lib64/libc.so.6 #11 0x00002b236701e9b0 in abort () from /lib64/libc.so.6 #12 0x00002b236705df1a in ?? () from /lib64/libc.so.6 #13 0x00002b23670640d7 in ?? () from /lib64/libc.so.6 #14 0x0000000000b2684d in xrealloc (oldmem=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/libiberty/xmalloc.c:179 #15 0x000000000083e528 in vec_heap_o_reserve_1 (vec=0x2b23ea786010, reserve=Unhandled dwarf ex pression opcode 0xf3 ) at ../../gcc/gcc/vec.c:313 #16 0x00000000005ea27f in VEC_inline_edge_summary_t_heap_reserve_exact ( alloc_=<value optimized out>, vec_=<value optimized out>) at ../../gcc/gcc/ipa-inline.h:128 #17 VEC_inline_edge_summary_t_heap_safe_grow (alloc_=<value optimized out>, vec_=<value optimized out>) at ../../gcc/gcc/ipa-inline.h:128 #18 VEC_inline_edge_summary_t_heap_safe_grow_cleared (alloc_=<value optimized out>, vec_=<value optimized out>) at ../../gcc/gcc/ipa-inline.h:128 #19 inline_summary_alloc (alloc_=<value optimized out>, vec_=<value optimized out>) at ../../gcc/gcc/ipa-inline-analysis.c:646 #20 0x00000000005ea3c1 in inline_edge_duplication_hook (src=0x2b2499f41680, dst=0x2b243e2d7680, data=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/ipa-inline-analysis.c:853 #21 0x00000000004e995c in cgraph_call_edge_duplication_hooks (cs2=0x2b243e2d7680, cs1=0x2b2499f41680) at ../../gcc/gcc/cgraph.c:376 #22 cgraph_clone_edge (cs2=0x2b243e2d7680, cs1=0x2b2499f41680) at ../../gcc/gcc/cgraph.c:2127 #23 0x00000000004e9c1d in cgraph_clone_node (n=0x2b2499f286f0, decl=0x2b2395b15500, count=Unha ndled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/cgraph.c:2196 #24 0x00000000005eeb9f in clone_inlined_nodes (e=0x2b2499f4a6e8, duplicate=1 '\001', update_original=1 '\001', overall_size=0x102e488)
Some updates: I tried with a fresh compiler (20110604). Same malloc assert I also checked with a somewhat older compiler (from around May 11) It segfaulted eventually too, so I suspect the problem has been there for longer.
I found a workaround: disabling -fcoverage-arcs (gcov) makes it go away.
I suppose we keep pointers to inline summaries live across the growth.
> I suppose we keep pointers to inline summaries live across the growth. Well, we should not. It is resized in inline_summary_alloc () and that function is called always before we get any pointers out...
It seems GCOV is not the only cause. I just got the malloc corruption again when building for 32bit (instead of 64bit), but still with gcov disabled. So probably for the other build disabling gcov just hid it. lto1: malloc.c:3551: munmap_chunk: Assertion `ret == 0' failed. lto1: internal compiler error: Aborted Very nasty. Any ideas how to track that down? Is valgrind supposed to work?
Hi, still stuck on this problem? vlagrind or libefence should do the job given enough time& memory. Honza
I haven't tried 32bit or GCOV recently, so not sure. I can try next time. I was still stuck on the other problem with the confused linker plugin ids.
Haven't seen this for some time with different builds, so it's probably fixed