Re: [PATCH] Try harder to fix recently introduced crashes in ggc_collect

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

On 05/19/17 09:51, Richard Biener wrote:
> On Thu, 18 May 2017, Bernd Edlinger wrote:
> 
>> Hi,
>>
>> unfortunately the first patch was still insufficient.  I identified many
>> more relatively new places where static tree objects are invisible to
>> GC.
>>
>> Nathan, whatever you are doing, please do it a bit more slowly, thanks.
>>
>> Bootstrap and reg-testing on x86_64-pc-linux-gnu in progress.
>> Is it OK after successful reg-testing?
> 
> Index: gcc/c-family/c-format.c
> ===================================================================
> --- gcc/c-family/c-format.c     (revision 248242)
> +++ gcc/c-family/c-format.c     (working copy)
> @@ -55,6 +55,8 @@ struct function_format_info
>   
>   /* Initialized in init_dynamic_diag_info.  */
>   static GTY(()) tree local_tree_type_node;
> +static GTY(()) tree hwi;
> +static GTY(()) tree locus;
>   
>   static bool decode_format_attr (tree, function_format_info *, int);
>   static int decode_format_type (const char *);
> @@ -3675,8 +3677,6 @@ find_length_info_modifier_index (const format_leng
>   static void
>   init_dynamic_asm_fprintf_info (void)
>   {
> -  static tree hwi;
> -
>     if (!hwi)
>       {
>         format_length_info *new_asm_fprintf_length_specs;
> @@ -3734,8 +3734,6 @@ init_dynamic_asm_fprintf_info (void)
>   static void
>   init_dynamic_gfc_info (void)
>   {
> -  static tree locus;
> -
>     if (!locus)
>       {
>         static format_char_info *gfc_fci;
> @@ -3828,8 +3826,6 @@ init_dynamic_diag_info (void)
>          local_tree_type_node = void_type_node;
>       }
>   
> -  static tree hwi;
> -
> 
> you are commoning 'hwi' here.   Also a bad (very short) name for a global
> (even if static).
> 
> I'll leave review to Nathan anyway.
> 
> Richard.
> 

Hmm, yes, I'll drop the 'hwi' change, thus only
move 'locus' because:

hwi cannot be the root cause of the problem,
because it can only be long_integer_type_node
or long_long_integer_type_node, otherwise
an error would be triggered.


>>
>> Thanks
>> Bernd.
>>
>>
>> On 05/18/17 17:33, Richard Biener wrote:
>>> On May 18, 2017 5:15:43 PM GMT+02:00, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
>>>> Hi,
>>>>
>>>>
>>>> this attempts to fix occasional segmentation faults that are present in
>>>> the current snapshot, while previous snapshot was stable.
>>>>
>>>> I observed numerous crashes but all were non-reproducible,
>>>> like the following example:
>>>>
>>>> In file included from
>>>> /home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/string:52:0,
>>>>                    from
>>>> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_config.h:19,
>>>>                    from
>>>> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_test_utils.h:17,
>>>>                    from
>>>> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test.cc:12,
>>>>                    from
>>>> /home/ed/gnu/gcc-8-20170514-1/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc:2:
>>>> /home/ed/gnu/gcc-build-1/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:6277:22:
>>>>
>>>> internal compiler error: Segmentation fault
>>>> 0xd7e17f crash_signal
>>>>           ../../gcc-8-20170514-1/gcc/toplev.c:337
>>>> 0x8f23fe ggc_set_mark(void const*)
>>>>           ../../gcc-8-20170514-1/gcc/ggc-page.c:1546
>>>> 0x7e6a5f gt_ggc_mx_lang_tree_node(void*)
>>>>           ./gt-cp-tree.h:133
>>>> 0x7e8c7a gt_ggc_mx_lang_tree_node(void*)
>>>>           ./gt-cp-tree.h:235
>>>> 0x7e8882 gt_ggc_mx_lang_tree_node(void*)
>>>>           ./gt-cp-tree.h:365
>>>> 0x81b26d gt_ggc_mx_cp_binding_level(void*)
>>>>           ./gt-cp-name-lookup.h:72
>>>> 0x7e6d85 gt_ggc_mx_lang_tree_node(void*)
>>>>           ./gt-cp-tree.h:648
>>>> 0x7e8ad2 gt_ggc_mx_lang_tree_node(void*)
>>>>           ./gt-cp-tree.h:221
>>>> 0x7e8eeb gt_ggc_mx_lang_tree_node(void*)
>>>>           ./gt-cp-tree.h:337
>>>> 0x7e8a3c gt_ggc_mx_lang_tree_node(void*)
>>>>           ./gt-cp-tree.h:441
>>>> 0x7e7304 gt_ggc_mx_lang_tree_node(void*)
>>>>           ./gt-cp-tree.h:606
>>>> 0x81b352 gt_ggc_mx_cxx_binding(void*)
>>>>           ./gt-cp-name-lookup.h:60
>>>> 0x7e6d85 gt_ggc_mx_lang_tree_node(void*)
>>>>           ./gt-cp-tree.h:648
>>>> 0x7e8ef5 gt_ggc_mx_lang_tree_node(void*)
>>>>           ./gt-cp-tree.h:336
>>>> 0x7e8a3c gt_ggc_mx_lang_tree_node(void*)
>>>>           ./gt-cp-tree.h:441
>>>> 0xb2edbe void gt_ggc_mx<tree_node*>(vec<tree_node*, va_gc, vl_embed>*)
>>>>           ../../gcc-8-20170514-1/gcc/vec.h:1110
>>>> 0xb2edbe gt_ggc_mx_vec_tree_va_gc_(void*)
>>>>           /home/ed/gnu/gcc-build-1/gcc/gtype-desc.c:1737
>>>> 0xac59f5 ggc_mark_root_tab
>>>>           ../../gcc-8-20170514-1/gcc/ggc-common.c:77
>>>> 0xac5c50 ggc_mark_roots()
>>>>           ../../gcc-8-20170514-1/gcc/ggc-common.c:94
>>>> 0x8f2de7 ggc_collect()
>>>>           ../../gcc-8-20170514-1/gcc/ggc-page.c:2206
>>>> Please submit a full bug report,
>>>> with preprocessed source if appropriate.
>>>> Please include the complete backtrace with any bug report.
>>>>
>>>>
>>>> The following patch fixes one rather suspicious static tree
>>>> object that did not have the GTY attribute, and was therefore
>>>> apparently not in the GC root set.
>>>>
>>>>
>>>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>>>> Is it OK for trunk?
>>>
>>> OK.
>>>
>>> Richard.
>>>
>>>>
>>>> Thanks
>>>> Bernd.
>>>
>>
>