[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Ah, ok. We come via TYPE_CANONICAL of sizetype * to some other type. Not sure how that happens though. Anyway, closing as fixed.
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #10 from Martin Liška ---
Second part of suggested patch is sufficient.
ps auxf:
marxin 20293 0.0 0.0 8604 1200 pts/0S17:27 0:00 | \_
c++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L.
-Wl,-uIsHeapProfilerRunning,-uProfilerStart
-Wl,-u_Z21InitialMallocHook_NewPKvj,-u_Z22Init
marxin 20294 0.0 0.0 8128 692 pts/0S17:27 0:00 |
\_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/collect2
-plugin /home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.
marxin 20295 1.1 7.2 3881556 1181360 pts/0 S17:27 0:03 |
\_
/home/marxin/Programming/bin/gcc/lib64/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/bin/ld
-plugin /home/marxin/Programming/bi
marxin 20412 0.0 0.1 34448 27212 pts/0S17:28 0:00 |
\_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
@/tmp/ccw1zmZQ
marxin 20413 0.0 0.0 12060 4548 pts/0S17:28 0:00 |
\_ c++ @/tmp/ccH68rYD.args
marxin 20414 23.7 33.4 5533676 5489912 pts/0 t17:28 0:54 |
\_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto1
-quiet -dumpdir ./ -dumpbase chrome.wpa -mtune=generic -march=x8
ps ax | grep 20414:
20414 pts/0t 0:54
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto1
-quiet -dumpdir ./ -dumpbase chrome.wpa -mtune=generic -march=x86-64 -msse2
-mssse3 -msse -mmmx -m64 -mtune=generic -march=x86-64 -auxbase
chrome_initial.chrome_exe_main_aura -O3 -fno-trapv -fno-exceptions -fPIC
-fno-fat-lto-objects -fltrans-output-list=/tmp/ccqDrHsV.ltrans.out -fwpa=9
-fresolution=/tmp/ccufR16A.res @/tmp/cc13JyyZ
GDB:
#1409777 0x006b3b11 in gt_ggc_m_P9tree_node4htab (x_p=0x7f0f55752850)
at gtype-desc.c:3185
(gdb) p *x
$2 = {hash_f = 0x75a1f0 , eq_f = 0x75a200
, del_f = 0x0, entries =
0x7f0f54390a00, size = 61, n_elements = 17, n_deleted = 0, searches = 17,
collisions = 4,
alloc_f = 0x681250 , free_f = 0x549db0 , alloc_arg = 0x0,
alloc_with_arg_f = 0x0, free_with_arg_f = 0x0, size_prime_index = 3}
down iterations:
(gdb) p x->generic->base->code
$7 = FUNCTION_DECL
$8 = FUNCTION_TYPE
$9 = INTEGER_TYPE
$10 = INTEGER_CST
$11 = INTEGER_TYPE
$12 = INTEGER_CST
$13 = INTEGER_TYPE
$14 = POINTER_TYPE
$15 = POINTER_TYPE
$16 = POINTER_TYPE
$17 = POINTER_TYPE
$18 = POINTER_TYPE
$19 = INTEGER_TYPE
Hope it will help.
Martin
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553 --- Comment #9 from Richard Biener --- Author: rguenth Date: Wed Mar 19 15:37:28 2014 New Revision: 208682 URL: http://gcc.gnu.org/viewcvs?rev=208682&root=gcc&view=rev Log: 2014-03-19 Richard Biener PR middle-end/60553 * tree-core.h (tree_type_common): Re-order pointer members to reduce recursion depth during GC walks. lto/ * lto-tree.h (lang_tree_node): For types use TYPE_NEXT_VARIANT instead of TREE_CHAIN as chain_next. Modified: trunk/gcc/ChangeLog trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-tree.h trunk/gcc/tree-core.h
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553 --- Comment #8 from Richard Biener --- I've posted the patches but I'm curious if the 2nd change alone helps enough. The first is somewhat handwaving (because we also have type_non_common which breaks the argument of the former).
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553 --- Comment #7 from Martin Liška --- Patches helped me! First one was sufficient for my simplified case (~800 files), but it was necessary to add second one for chromium. Will you add this changes to mainline or should I create a patch? Thanks, Martin
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #6 from Richard Biener ---
Another idea would be (many next-variant walks in the call stack)
Index: lto/lto-tree.h
===
--- lto/lto-tree.h (revision 208615)
+++ lto/lto-tree.h (working copy)
@@ -48,7 +48,7 @@ enum lto_tree_node_structure_enum {
};
union GTY((desc ("lto_tree_node_structure (&%h)"),
- chain_next ("CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic),
TS_COMMON) ? ((union lang_tree_node *) TREE_CHAIN (&%h.generic)) : NULL")))
+ chain_next ("CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic),
TS_TYPE_COMMON) ? ((union lang_tree_node *) TYPE_NEXT_VARIANT (&%h.generic)) :
CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic), TS_COMMON) ? ((union
lang_tree_node *) TREE_CHAIN (&%h.generic)) : NULL")))
lang_tree_node
{
union tree_node GTY ((tag ("TS_LTO_GENERIC"),
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #5 from Richard Biener ---
next_variant->type_name->type->next_variant->type-name->decl_original_type->type_name->decl_context->next_variant->type_context->next_variant->next_variant->next_variant->type_fields->type->...
it's walking a type hierarchy, up-and-down. Ideally the GC walking would
be more structured here, but ...
Can you try if sth as simple as
Index: gcc/tree-core.h
===
--- gcc/tree-core.h (revision 208615)
+++ gcc/tree-core.h (working copy)
@@ -1265,11 +1265,11 @@ struct GTY(()) tree_type_common {
const char * GTY ((tag ("TYPE_SYMTAB_IS_POINTER"))) pointer;
struct die_struct * GTY ((tag ("TYPE_SYMTAB_IS_DIE"))) die;
} GTY ((desc ("debug_hooks->tree_type_symtab_field"))) symtab;
- tree name;
+ tree canonical;
tree next_variant;
tree main_variant;
tree context;
- tree canonical;
+ tree name;
};
struct GTY(()) tree_type_with_lang_specific {
helps? That makes sure to first walk fields that point us downward the
type hierarchy and then those that point us upward?
With LTO it may be the case that TYPE_CANONICAL connects very many types
that are otherwise unrelated ...
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553 --- Comment #4 from Martin Liška --- Created attachment 32375 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32375&action=edit bt 1000
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553 --- Comment #3 from Martin Liška --- Created attachment 32374 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32374&action=edit gtype-lto.h
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #2 from Martin Liška ---
Reduced input object files to ~800, bt consists of ~66K frames.
gdb:
(gdb) bt 10
#0 0x005cec2c in lookup_page_table_entry (p=) at ../../gcc/ggc-page.c:584
#1 0x005cfc5e in ggc_set_mark (p=0x7feaf406c020) at
../../gcc/ggc-page.c:1467
#2 0x005a9222 in gt_ggc_mx_lang_tree_node (x_p=0x7feaf406c020) at
./gtype-lto.h:36
#3 0x005aae37 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec684bd0) at
./gtype-lto.h:356
#4 0x005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec6ad398) at
./gtype-lto.h:243
#5 0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68af18) at
./gtype-lto.h:374
#6 0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68c2a0) at
./gtype-lto.h:375
#7 0x005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec695e60) at
./gtype-lto.h:243
#8 0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec69a0a8) at
./gtype-lto.h:374
#9 0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec697d20) at
./gtype-lto.h:375
#2 0x005a9222 in gt_ggc_mx_lang_tree_node (x_p=0x7feaf406c020) at
./gtype-lto.h:36
36 while (ggc_test_and_set_mark (xlimit))
(gdb) print (*x).generic.base
$20 = {code = INTEGER_CST, side_effects_flag = 0, constant_flag = 1,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0,
public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0,
saturating_flag = 0, unsigned_flag = 0, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 0, version = 0}}
(gdb) up
#3 0x005aae37 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec684bd0) at
./gtype-lto.h:356
356 gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.size);
(gdb) print (*x).generic.base
$21 = {code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0,
public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0,
saturating_flag = 0, unsigned_flag = 1, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 256, version = 256}}
(gdb) up
#4 0x005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec6ad398) at
./gtype-lto.h:243
243 gt_ggc_m_9tree_node
((*x).generic.type_decl.common.common.common.common.common.common.typed.type);
(gdb) print (*x).generic.base
$22 = {code = TYPE_DECL, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0,
public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0,
saturating_flag = 0, unsigned_flag = 1, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 256, version = 256}}
(gdb) up
#5 0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68af18) at
./gtype-lto.h:374
374 gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.name);
(gdb) print (*x).generic.base
$23 = {code = RECORD_TYPE, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 1, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0,
public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0,
saturating_flag = 0, unsigned_flag = 0, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 0, version = 0}}
(gdb) up
#6 0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68c2a0) at
./gtype-lto.h:375
375 gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.next_variant);
(gdb) print (*x).generic.base
$24 = {code = RECORD_TYPE, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 1, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarni
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553 --- Comment #1 from Richard Biener --- (In reply to Martin Liška from comment #0) > I do compile Chromium with LTO and there's ICE with enormous call stack: > > gcc --version: > gcc (GCC) 4.9.0 20140313 (experimental) > > (gdb) bt 10 > #0 0x005cec2c in lookup_page_table_entry (p= variable: Cannot access memory at address 0x7fffa80e8fc8>) at > ../../gcc/ggc-page.c:584 > #1 0x005cfc5e in ggc_set_mark (p=0x7f5c399c1170) at > ../../gcc/ggc-page.c:1467 > #2 0x005a9222 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c1170) at > ./gtype-lto.h:36 > #3 0x005aae1a in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c6f18) at > ./gtype-lto.h:355 > #4 0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c6e70) at > ./gtype-lto.h:375 > #5 0x005aa4b8 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c10b8) at > ./gtype-lto.h:246 > #6 0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c60a8) at > ./gtype-lto.h:374 > #7 0x005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bf5e8) at > ./gtype-lto.h:375 > #8 0x005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bae60) at > ./gtype-lto.h:243 > #9 0x005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bf348) at > ./gtype-lto.h:374 > > I don't know what to dump, if you are interested I can add all kind info you > need. Can you show what lines you have in gtype-lto.h at these points? I have stuff that doesn't make much sense #3 gt_ggc_m_9tree_node ((*x).generic.type_non_common.with_lang_specific.common.common.chain) #4 gt_ggc_m_9tree_node ((*x).generic.type_non_common.with_lang_specific.common.next_variant); #5 gt_ggc_m_9tree_node ((*x).generic.type_decl.common.common.common.common.common.context); #6 gt_ggc_m_9tree_node ((*x).generic.type_non_common.with_lang_specific.common.name); #7 gt_ggc_m_9tree_node ((*x).generic.type_non_common.with_lang_specific.common.next_variant); #8 gt_ggc_m_9tree_node ((*x).generic.type_decl.common.common.common.common.common.common.typed.type); #9 gt_ggc_m_9tree_node ((*x).generic.type_non_common.with_lang_specific.common.name); so it seems to be following a variant chain (but of course bt 10 may just not be enough to see the real problem).
