[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).

Fri Dec 28 08:19:00 GMT 2018

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.