| Message ID | 20111020101408.GA5751@host1.jankratochvil.net |
|---|---|
| State | New |
| Headers | show |
On Thu, Oct 20, 2011 at 12:14 PM, Jan Kratochvil <jan.kratochvil@redhat.com> wrote: > Hi, > > with custom patched dwarf2out.c I got a crash on memory mangled by the garbage > collector. With patched GTY there the crash no longer happened - but I do not > have a reproducer anymore, sorry if it is a bogus patch. > > The memory corrupted later was initially allocated and stored into > mem_loc_result->dw_loc_oprnd1.v.val_loc. I do not think there is any other > reference to it than that field with no GTY. > > GIT 33e7b55c2549d655d88ec64c06c51912d0d07527 > gcc (GCC) 4.7.0 20111002 (experimental) > > 11900 mem_loc_result->dw_loc_oprnd1.v.val_loc = op0; > (gdb) bt > #0 mem_loc_descriptor (rtl=, mode=SImode, mem_mode=VOIDmode, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:11900 > #1 in loc_descriptor (rtl=, mode=SImode, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12790 > #2 in loc_descriptor (rtl=, mode=SImode, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12614 > #3 in dw_loc_list_1 (loc=, varloc=, want_address=2, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12889 > #4 in dw_loc_list (loc_list=, decl=, want_address=2) at gcc/dwarf2out.c:13145 > #5 in loc_list_from_tree (loc=, want_address=2) at gcc/dwarf2out.c:13538 > #6 in add_location_or_const_value_attribute (die=, decl=, cache_p=0 '\000', attr=DW_AT_location) at gcc/dwarf2out.c:15048 > #7 in gen_formal_parameter_die (node=, origin=0x0, emit_name_p=1 '\001', context_die=) at gcc/dwarf2out.c:16804 > #8 in gen_decl_die (decl=, origin=0x0, context_die=) at gcc/dwarf2out.c:19632 > #9 in gen_subprogram_die (decl=, context_die=) at gcc/dwarf2out.c:17560 > #10 in gen_decl_die (decl=, origin=0x0, context_die=) at gcc/dwarf2out.c:19545 > #11 in dwarf2out_decl (decl=) at gcc/dwarf2out.c:19919 > #12 in dwarf2out_function_decl (decl=) at gcc/dwarf2out.c:19927 > #13 in rest_of_handle_final () at gcc/final.c:4252 > #14 in execute_one_pass (pass=0x4dbe120) at gcc/passes.c:2064 > #15 in execute_pass_list (pass=0x4dbe120) at gcc/passes.c:2119 > #16 in execute_pass_list (pass=0x4dbef00) at gcc/passes.c:2120 > #17 in execute_pass_list (pass=0x4dbeea0) at gcc/passes.c:2120 > #18 in tree_rest_of_compilation (fndecl=) at gcc/tree-optimize.c:420 > #19 in cgraph_expand_function (node=) at gcc/cgraphunit.c:1803 > #20 in cgraph_expand_all_functions () at gcc/cgraphunit.c:1862 > #21 in cgraph_optimize () at gcc/cgraphunit.c:2133 > #22 in cgraph_finalize_compilation_unit () at gcc/cgraphunit.c:1310 > #23 in c_write_global_declarations () at gcc/c-decl.c:9936 > #24 in compile_file () at gcc/toplev.c:581 > #25 in do_compile () at gcc/toplev.c:1925 > #26 in toplev_main (argc=101, argv=) at gcc/toplev.c:2001 > #27 in main (argc=101, argv=) at gcc/main.c:36 > > It was later freed (watchpoint hit) by: > > (gdb) bt > #0 __memset_sse2 () at ../sysdeps/x86_64/memset.S:333 > #1 in poison_pages () at gcc/ggc-page.c:1845 > #2 in ggc_collect () at gcc/ggc-page.c:1938 > #3 in execute_todo (flags=2) at gcc/passes.c:1763 > #4 in execute_one_pass (pass=0x4dbce80) at gcc/passes.c:2087 > #5 in execute_pass_list (pass=0x4dbce80) at gcc/passes.c:2119 > #6 in tree_rest_of_compilation (fndecl=) at gcc/tree-optimize.c:420 > #7 in cgraph_expand_function (node=) at gcc/cgraphunit.c:1803 > #8 in cgraph_expand_all_functions () at gcc/cgraphunit.c:1862 > #9 in cgraph_optimize () at gcc/cgraphunit.c:2133 > #10 in cgraph_finalize_compilation_unit () at gcc/cgraphunit.c:1310 > #11 in c_write_global_declarations () at gcc/c-decl.c:9936 > #12 in compile_file () at gcc/toplev.c:581 > #13 in do_compile () at gcc/toplev.c:1925 > #14 in toplev_main (argc=101, argv=) at gcc/toplev.c:2001 > #15 in main (argc=101, argv=) at gcc/main.c:36 > > And later it crashed on the mangled memory. > > > OK to check it in? No regression testing done. I don't see how it can make any difference. Richard. > > Thanks, > Jan > > > gcc/ > 2011-10-20 Jan Kratochvil <jan.kratochvil@redhat.com> > > * dwarf2out.c (struct dw_loc_list_struct): Add GTY for expr; > > --- a/gcc/dwarf2out.c > +++ b/gcc/dwarf2out.c > @@ -1211,7 +1210,7 @@ typedef struct GTY(()) dw_loc_list_struct { > char *ll_symbol; /* Label for beginning of location list. > Only on head of list */ > const char *section; /* Section this loclist is relative to */ > - dw_loc_descr_ref expr; > + dw_loc_descr_ref GTY(()) expr; > hashval_t hash; > /* True if all addresses in this and subsequent lists are known to be > resolved. */ >
On Thu, Oct 20, 2011 at 12:21:58PM +0200, Richard Guenther wrote: > I don't see how it can make any difference. Indeed, I see no changes in gt-dwarf2out.h with the patch. So it doesn't do anything. > > 2011-10-20 Jan Kratochvil <jan.kratochvil@redhat.com> > > > > * dwarf2out.c (struct dw_loc_list_struct): Add GTY for expr; > > > > --- a/gcc/dwarf2out.c > > +++ b/gcc/dwarf2out.c > > @@ -1211,7 +1210,7 @@ typedef struct GTY(()) dw_loc_list_struct { > > char *ll_symbol; /* Label for beginning of location list. > > Only on head of list */ > > const char *section; /* Section this loclist is relative to */ > > - dw_loc_descr_ref expr; > > + dw_loc_descr_ref GTY(()) expr; > > hashval_t hash; > > /* True if all addresses in this and subsequent lists are known to be > > resolved. */ > > Jakub
2011/10/20 Jan Kratochvil <jan.kratochvil@redhat.com>: > Hi, > > with custom patched dwarf2out.c I got a crash on memory mangled by the garbage > collector. With patched GTY there the crash no longer happened - but I do not > have a reproducer anymore, sorry if it is a bogus patch. > > The memory corrupted later was initially allocated and stored into > mem_loc_result->dw_loc_oprnd1.v.val_loc. I do not think there is any other > reference to it than that field with no GTY. > 2011-10-20 Jan Kratochvil <jan.kratochvil@redhat.com> > > * dwarf2out.c (struct dw_loc_list_struct): Add GTY for expr; This patch is a no-op, as already pointed out. If this comes up again, I'd set a conditional breakpoint on ggc_set_mark if (arg == struct dw_loc_list_struct with the field that gets collected) and try to find out why the field does not get marked.
On Fri, 21 Oct 2011 05:37:09 +0200, Laurynas Biveinis wrote: > This patch is a no-op, as already pointed out. If this comes up again, > I'd set a conditional breakpoint on ggc_set_mark if (arg == struct > dw_loc_list_struct with the field that gets collected) and try to find > out why the field does not get marked. Thanks all for the review, I see I do not know the GC. I thought the bug is so obvious... I did not make a snapshot of the tree in that crashing state. Therefore I cannot say anything useful about the crash anymore. Thanks, Jan
FYI: I am seeing this same ICE on the hppa64-hp-hpux11.11 bootstrap. (debug_expr:DI D#49) /ctires/gcc/nightly/src/trunk/gcc/cselib.c: In function 'void cselib_record_sets(rtx)': /ctires/gcc/nightly/src/trunk/gcc/cselib.c:2424:1: internal compiler error: in mem_loc_descriptor, at dwarf2out.c:12379 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. I am trying to cut down the test case and find out exactly when it started failing. The last successful bootstrap I had was r180174 and the first known bad one is r180233. Steve Ellcey sje@cup.hp.com
On Fri, Oct 21, 2011 at 09:54:56AM -0700, Steve Ellcey wrote: > FYI: I am seeing this same ICE on the hppa64-hp-hpux11.11 bootstrap. > > (debug_expr:DI D#49) > /ctires/gcc/nightly/src/trunk/gcc/cselib.c: In function 'void cselib_record_sets(rtx)': > /ctires/gcc/nightly/src/trunk/gcc/cselib.c:2424:1: internal compiler error: in mem_loc_descriptor, at dwarf2out.c:12379 > Please submit a full bug report, > with preprocessed source if appropriate. > See <http://gcc.gnu.org/bugs.html> for instructions. > > I am trying to cut down the test case and find out exactly when > it started failing. The last successful bootstrap I had was r180174 and > the first known bad one is r180233. My guess would be http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180194 DEBUG_EXPR certainly shouldn't make it through into mem_loc_descriptor, var-tracking is supposed to resolve that. Jakub
On Fri, 2011-10-21 at 21:25 +0200, Jakub Jelinek wrote: > My guess would be > http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180194 > DEBUG_EXPR certainly shouldn't make it through into mem_loc_descriptor, > var-tracking is supposed to resolve that. > > Jakub You are right, the bug started at r180194. I have submitted a bug (PR 50826) which includes a cut down test case for the problem. Steve Ellcey sje@cup.hp.com
--- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -1211,7 +1210,7 @@ typedef struct GTY(()) dw_loc_list_struct { char *ll_symbol; /* Label for beginning of location list. Only on head of list */ const char *section; /* Section this loclist is relative to */ - dw_loc_descr_ref expr; + dw_loc_descr_ref GTY(()) expr; hashval_t hash; /* True if all addresses in this and subsequent lists are known to be resolved. */