Bug 1531154 - G++ 7.2.1 segmentation fault when building with -O3 -g
Summary: G++ 7.2.1 segmentation fault when building with -O3 -g
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: gcc
Version: DTS 7.0 RHEL 7
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: alpha
: 7.1
Assignee: Marek Polacek
QA Contact: Martin Cermak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-04 16:57 UTC by Yitzik Casapu
Modified: 2020-12-04 04:33 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-04 04:34:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Preprocessed source produced by G++ for error reporting (8.15 MB, text/x-csrc)
2018-01-04 16:57 UTC, Yitzik Casapu
no flags Details

Description Yitzik Casapu 2018-01-04 16:57:29 UTC
Created attachment 1377022 [details]
Preprocessed source produced by G++ for error reporting

Description of problem:
Invocation of G++ as 'g++ -std=c++1y -DONIX_MJ_VERSION=6 -DONIX_MN_VERSION=0 -DRUN_MODE_SIMULATOR=1 -D_GLIBCXX_USE_CXX11_ABI=0 -DMARKET_DATA_RX_TIMING_INSTRUMENTATION=1 -I../../External/include/zmq -I../../Signals -I../../External/include -I../../Lib/H5DataReader/ -I../../External/include/hdf5 -I../../External/include/protobuf -I../../External/include/Onix/ex-current -I../../External/include/Onix/md-current -I../. -O3 -g -Wall -isystem ../../External/include -c -fmessage-length=0 -fPIC -o Connectivity/Tmbuk/TmbukWlcjSnapshotListener.o ../Connectivity/Tmbuk/TmbukWlcjSnapshotListener.cpp
' causes G++ to abort with a segmentation fault

Version-Release number of selected component (if applicable):
g++ (GCC) 7.2.1 20170829 from Centos 7.4 devtoolset-7, installed using yum

How reproducible:
100% consistent on my setup with the full source tree. Note however that it doesn't reproduce when running on the attached preprocessed source file.

Steps to Reproduce:

cc1plus segmentation fault. GDB transcript:
<code>
Thread 2.1 "cc1plus" received signal SIGSEGV, Segmentation fault.
[Switching to process 36594]
lookup_page_table_entry (p=0x100000004) at ../../gcc/ggc-page.c:635
635	  while (table->high_bits != high_bits)
Missing separate debuginfos, use: debuginfo-install gmp-6.0.0-15.el7.x86_64 libmpc-1.0.1-3.el7.x86_64 mpfr-3.1.1-4.el7.x86_64
(gdb) bt
#0  lookup_page_table_entry (p=0x100000004) at ../../gcc/ggc-page.c:635
#1  0x0000000000675bdf in ggc_set_mark (p=p@entry=0x100000004) at ../../gcc/ggc-page.c:1532
#2  0x0000000000e99930 in gt_ggc_mx_lang_tree_node(void*) () at ./gt-cp-tree.h:133
#3  0x000000000060defc in gt_ggc_mx (x_r=...) at ./gt-cp-semantics.h:37
#4  0x000000000060c69f in gt_ggc_mx<deferred_access_check> (v=<optimized out>) at ../../gcc/vec.h:1110
#5  gt_ggc_mx_vec_deferred_access_check_va_gc_ (x_p=0x7fffd6cca870) at ./gt-cp-semantics.h:28
#6  0x00000000005ee683 in gt_ggc_mx_tree_check (x_p=0x7fffd6ca63d8) at ./gt-cp-parser.h:38
#7  0x00000000005ecfd0 in gt_ggc_mx<cp_token> (v=<optimized out>) at ../../gcc/vec.h:1110
#8  gt_ggc_mx_vec_cp_token_va_gc_ (x_p=0x7fffe51ce000) at ./gt-cp-parser.h:49
#9  0x00000000005ecef5 in gt_ggc_mx_cp_lexer (x_p=<optimized out>) at ./gt-cp-parser.h:76
#10 0x00000000005ece60 in gt_ggc_mx_cp_parser (x_p=0x7fffe2f7ed80) at ./gt-cp-parser.h:136
#11 0x000000000073f0c3 in ggc_mark_root_tab (rt=0x1501a20 <gt_ggc_r_gt_cp_parser_h>) at ../../gcc/ggc-common.c:77
#12 0x000000000073f21d in ggc_mark_roots () at ../../gcc/ggc-common.c:94
#13 0x00000000006751d9 in ggc_collect () at ../../gcc/ggc-page.c:2202
#14 0x0000000000f3e409 in cgraph_node::finalize_function(tree_node*, bool) () at ../../gcc/cgraphunit.c:480
#15 0x0000000000e8a106 in expand_or_defer_fn(tree_node*) () at ../../gcc/cp/semantics.c:4277
#16 0x0000000000e60b4f in cp_parser_function_definition_after_declarator(cp_parser*, bool) () at ../../gcc/cp/parser.c:26293
#17 0x0000000000e4e662 in cp_parser_function_definition_from_specifiers_and_declarator (declarator=0x2642be0, attributes=0x0, decl_specifiers=0x5ecfd0 <gt_ggc_mx_vec_cp_token_va_gc_(void*)+49>, parser=0x7fffe2f7ed80)
    at ../../gcc/cp/parser.c:26196
#18 cp_parser_init_declarator(cp_parser*, cp_decl_specifier_seq*, vec<deferred_access_check, va_gc, vl_embed>*, bool, bool, int, bool*, tree_node**, unsigned int*, tree_node**) () at ../../gcc/cp/parser.c:19182
#19 0x0000000000e4bad4 in cp_parser_simple_declaration(cp_parser*, bool, tree_node**) () at ../../gcc/cp/parser.c:12786
#20 0x0000000000e4b2d6 in cp_parser_block_declaration(cp_parser*, bool) () at ../../gcc/cp/parser.c:12611
#21 0x0000000000e4afba in cp_parser_declaration(cp_parser*) () at ../../gcc/cp/parser.c:12509
#22 0x0000000000e4accf in cp_parser_declaration_seq_opt (parser=parser@entry=0x7fffe2f7ed80) at ../../gcc/cp/parser.c:12385
#23 0x00000000013cdc45 in cp_parser_translation_unit (parser=0x7fffe2f7ed80) at ../../gcc/cp/parser.c:4368
#24 c_parse_file() () at ../../gcc/cp/parser.c:38454
#25 0x00000000013e5033 in c_common_parse_file() () at ../../gcc/c-family/c-opts.c:1107
#26 0x0000000001435c58 in compile_file() () at ../../gcc/toplev.c:470
#27 0x0000000000dd56d0 in do_compile () at ../../gcc/toplev.c:2006
#28 toplev::main(int, char**) () at ../../gcc/toplev.c:2142
#29 0x0000000000dd6fbb in main () at ../../gcc/main.c:39
#30 0x00007ffff6c32c05 in __libc_start_main (main=0xdd6f80 <main>, argc=51, ubp_av=0x7fffffffd9e8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd9d8) at ../csu/libc-start.c:274
#31 0x00000000013c2d2f in _start ()
(gdb) p table
$1 = (page_table) 0x0
</code>

Expected results:
A clean compilation of the code without errors or warnings, like I get with G++ 5.3.1 from Devtoolset-4

Additional info:
The filenames in the command line and the preprocessed code have been slightly obfuscated since this is proprietary production code. I can supply an unobfuscated version as well as the core file privately.

Comment 2 Marek Polacek 2018-01-05 13:11:12 UTC
Unfortunately, I can't reproduce it with the preprocessed source file even if I use --param ggc-min-expand=1 --param ggc-min-heapsize=0.

Comment 3 Yitzik Casapu 2018-01-06 06:56:11 UTC
Would a core-file be helpful? If so, how can I upload it given that its size would be around 80MB?
Alternatively, how can I quickly get a list of all the include files that my source file would require so I can build a stripped-down version of my source-tree that does reproduce the issue?

Comment 4 Yitzik Casapu 2018-01-08 12:23:48 UTC
I've tried to create a scaled-down version of the code that reproduces the issue, and it would still contain a sizable amount of proprietary code. I can only send it privately, pursuant to an understanding that it will not be made public.

Comment 5 Marek Polacek 2018-01-09 14:20:39 UTC
(In reply to Yitzik Casapu from comment #4)
> I've tried to create a scaled-down version of the code that reproduces the
> issue, and it would still contain a sizable amount of proprietary code. I
> can only send it privately, pursuant to an understanding that it will not be
> made public.

Thanks.  A core file wouldn't help much; what we need is a stand-alone test case that reproduces the issue.  Is this scaled-down version of the code a pre-processed source file (i.e. doesn't need any additional headers that I don't have access to)?  Anyway, you can send me the scaled-down version privately and I will try to reduce it to something minimal.  (Even if I succeed in reducing it, I won't make it public unless you explicitly approve.)

Comment 7 Yitzik Casapu 2018-01-15 15:31:35 UTC
Thanks Marek. I've sent you privately an archive with a source tree that can reproduce the issue + exact command-line. I've also tried to reproduce it with  the preprocessed source file generated by g++, but could not. Please let me know that you have received the source archive and that you g++ also segfaults with it on your setup.
I've also seen the issue with G++ 7.2.0 on an Ubuntu 16.04 workstation, which suggests it's not very setup specific.

Comment 8 Marek Polacek 2018-01-17 14:44:39 UTC
Unfortunately I couldn't reproduce the failure, so there's not much I can do, sorry.

If you ever find a different testcase that demonstrates the crash reliably, please reopen the BZ.

Comment 9 Brad Hubbard 2019-03-25 05:04:11 UTC
Reopening this since I can consistently reproduce it and provide access to the reproducer.

Comment 17 Brad Hubbard 2019-03-27 06:55:28 UTC
For those following this BZ, you may be able to work around this segfault by adding "--param ggc-min-expand=1 --param ggc-min-heapsize=0" to the compiler command line.

Comment 32 Marek Polacek 2019-07-09 19:33:41 UTC
Adjusting the component.  Not a problem with the container itself.

Comment 33 Marek Polacek 2020-01-14 21:43:18 UTC
I wanted to check but couldn't reproduce as the ./install-deps.sh step fails.  So moving to DTS 10.0 in the hope that maybe someone can try this with DTS 9.

Comment 34 Brad Hubbard 2020-01-14 23:38:25 UTC
(In reply to Marek Polacek from comment #33)
> I wanted to check but couldn't reproduce as the ./install-deps.sh step
> fails.  So moving to DTS 10.0 in the hope that maybe someone can try this
> with DTS 9.

I'll be in a position to attempt this next week and will report results.


Note You need to log in before you can comment on or make changes to this bug.