https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250
--- Comment #21 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Eric Gallager from comment #20) > (In reply to Jack Howarth from comment #16) > > (In reply to howarth from comment #15) > > > (In reply to howarth from comment #14) > > > > Testing https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01334.html in case > > > > correction of the overflow tests eliminates this bug. > > > > > > The proposed patch for correcting overflows doesn't eliminate this bug. > > > > With Jan's patch the failure still appears as... > > > > #0 0x00007fff96238286 in __pthread_kill () > > #1 0x00007fff9488042f in pthread_kill () > > #2 0x00007fff8e9c1b53 in abort () > > #3 0x0000000100f32170 in linemap_lookup (set=0x10175e0f0, line=651) at > > ../../gcc-5-20150326/libcpp/line-map.c:806 > > Since the crash is in libcpp, cc-ing libcpp maintainers As per my current analysis, the crash is in the GC/PCH code. * This is repeatable outside the testsuite (between 4 and 400 attempts to trigger), so not an issue with the test framework. * It does not appear to affect Linux (10,000 attempts, no fail). There are two different failure modes: (1) it crashes with some error reported from within ggc_pch_read() (2) it hangs with either a signal caused by, or a crash within, ggc_pch_read() * When the hang occurs it appears to be a deadlock in memory management related to the diagnostic messages. 2 Thread_56911430 DispatchQueue_1: com.apple.main-thread (serial) 2 start (in libdyld.dylib) + 1 [0x142809235] 2 main (in cc1) + 47 [0x101085d4f] main.c:39 2 toplev::main(int, char**) (in cc1) + 320 [0x100c90ce0] toplev.c:2311 2 do_compile() (in cc1) + 269 [0x100c911ad] toplev.c:2176 2 compile_file() (in cc1) + 58 [0x100c92caa] toplev.c:456 2 c_common_parse_file() (in cc1) + 97 [0x1000f0911] c-opts.c:1151 2 c_parse_file() (in cc1) + 169 [0x100068999] c-parser.c:19760 2 c_common_pch_pragma(cpp_reader*, char const*) (in cc1) + 82 [0x1000f15a2] c-pch.c:433 2 c_common_read_pch(cpp_reader*, char const*, int, char const*) (in cc1) + 167 [0x1000f1437] c-pch.c:368 2 gt_pch_restore(__sFILE*) (in cc1) + 480 [0x1008df630] ggc-common.c:631 2 ggc_pch_read(__sFILE*, void*) (in cc1) + 751 [0x1006a47ff] ggc-page.c:2588 2 fatal_error(unsigned int, char const*, ...) (in cc1) + 196 [0x1010a60c4] diagnostic.c:1488 2 diagnostic_impl(rich_location*, int, char const*, __va_list_tag (*) [1], diagnostic_t) (in cc1) + 128 [0x1010a4b30] diagnostic.c:1138 As for the bug: it seems related to the two different call arcs for ggc_pch_read() A) when called 'normally' * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x00000001006a452a cc1`ggc_pch_read(f=0x00007fffbbfd9148, addr=0x00000001018e9000) at ggc-page.c:2557 [opt] frame #1: 0x00000001008df630 cc1`gt_pch_restore(f=0x00007fffbbfd9148) at ggc-common.c:631 [opt] frame #2: 0x00000001000f1437 cc1`c_common_read_pch(pfile=0x0000000143001a00, name="./save-temps-1.h.gch", fd=<unavailable>, orig_name=<unavailable>) at c-pch.c:368 [opt] frame #3: 0x00000001010df8d4 cc1`should_stack_file(pfile=0x0000000143001a00, file=0x0000000142f04e80, import=false, loc=4975) at files.c:814 [opt] frame #4: 0x00000001010df758 cc1`::_cpp_stack_file(pfile=0x0000000143001a00, file=0x0000000142f04e80, import=<unavailable>, loc=<unavailable>) at files.c:900 [opt] frame #5: 0x00000001010dfb4c cc1`::_cpp_stack_include(pfile=0x0000000143001a00, fname="save-temps-1.h", angle_brackets=0, type=IT_INCLUDE, loc=<unavailable>) at files.c:1049 [opt] frame #6: 0x00000001010d92fd cc1`do_include_common(pfile=0x0000000143001a00, type=IT_INCLUDE) at directives.c:848 [opt] frame #7: 0x00000001010d6a28 cc1`::_cpp_handle_directive(pfile=0x0000000143001a00, indented=<unavailable>) at directives.c:543 [opt] frame #8: 0x00000001010e31b2 cc1`::_cpp_lex_token(pfile=0x0000000143001a00) at lex.c:2609 [opt] frame #9: 0x00000001010eb488 cc1`cpp_get_token_1(pfile=0x0000000143001a00, location=0x00007fff5fbff4bc) at macro.c:2703 [opt] frame #10: 0x00000001000e24fe cc1`c_lex_with_flags(value=0x00007fff5fbff4c0, loc=0x00007fff5fbff4bc, cpp_flags="", lex_flags=0) at c-lex.c:405 [opt] frame #11: 0x00000001000658b1 cc1`c_lex_one_token(parser=0x00007fff5fbff4b0, token=0x00007fff5fbff4b8) at c-parser.c:249 [opt] frame #12: 0x000000010006585a cc1`c_parser_peek_token(parser=0x00007fff5fbff4b0) at c-parser.c:436 [opt] frame #13: 0x0000000100068981 cc1`c_parse_file() at c-parser.c:19759 [opt] frame #14: 0x00000001000f0911 cc1`c_common_parse_file() at c-opts.c:1151 [opt] frame #15: 0x0000000100c92caa cc1`compile_file() at toplev.c:456 [opt] frame #16: 0x0000000100c911ad cc1`do_compile() at toplev.c:2176 [opt] frame #17: 0x0000000100c90ce0 cc1`toplev::main(this=0x00007fff5fbff690, argc=<unavailable>, argv=<unavailable>) at toplev.c:2311 [opt] B) when called for "-save-temps" it's triggered by processing #pragma GCC pch_preprocess "./save-temps-1.h.gch" * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x00000001006a452a cc1`ggc_pch_read(f=0x00007fffbbfd9148, addr=0x00000001018e9000) at ggc-page.c:2557 [opt] frame #1: 0x00000001008df630 cc1`gt_pch_restore(f=0x00007fffbbfd9148) at ggc-common.c:631 [opt] frame #2: 0x00000001000f1437 cc1`c_common_read_pch(pfile=0x0000000143801e00, name="./save-temps-1.h.gch", fd=<unavailable>, orig_name=<unavailable>) at c-pch.c:368 [opt] frame #3: 0x00000001000f15a2 cc1`c_common_pch_pragma(pfile=0x0000000143801e00, name="./save-temps-1.h.gch") at c-pch.c:433 [opt] frame #4: 0x0000000100068999 cc1`c_parse_file() at c-parser.c:19760 [opt] frame #5: 0x00000001000f0911 cc1`c_common_parse_file() at c-opts.c:1151 [opt] frame #6: 0x0000000100c92caa cc1`compile_file() at toplev.c:456 [opt] frame #7: 0x0000000100c911ad cc1`do_compile() at toplev.c:2176 [opt] frame #8: 0x0000000100c90ce0 cc1`toplev::main(this=0x00007fff5fbff7b0, argc=<unavailable>, argv=<unavailable>) at toplev.c:2311 [opt] frame #9: 0x0000000101085d4f cc1`main(argc=<unavailable>, argv=<unavailable>) at main.c:39 [opt] ====== possibly an MMAP issue .. Linux and Darwin have different implementations. There's some suspicious text in the GGC/PCH code that says it's OK to clear everything down, since it's all going to be restored from the PCH file. This seems reasonable in the 'normal' case - but I wonder if that's true when the PCH restore is triggered off a pragma in the .i file? Anyway ... next to try and determine whether this is an OS revision-related - or purely GCC-related regression.
