Patchwork dwarf2out crash: missing GTY? (PR 50806)

login
register
mail settings
Submitter Jan Kratochvil
Date Oct. 20, 2011, 10:14 a.m.
Message ID <20111020101408.GA5751@host1.jankratochvil.net>
Download mbox | patch
Permalink /patch/120782/
State New
Headers show

Comments

Jan Kratochvil - Oct. 20, 2011, 10:14 a.m.
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.


Thanks,
Jan


gcc/
2011-10-20  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* dwarf2out.c (struct dw_loc_list_struct): Add GTY for expr;
Richard Guenther - Oct. 20, 2011, 10:21 a.m.
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.  */
>
Jakub Jelinek - Oct. 20, 2011, 10:35 a.m.
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
Laurynas Biveinis - Oct. 21, 2011, 3:37 a.m.
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.
Jan Kratochvil - Oct. 21, 2011, 5:21 a.m.
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
Steve Ellcey - Oct. 21, 2011, 5:03 p.m.
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
Jakub Jelinek - Oct. 21, 2011, 7:25 p.m.
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
Steve Ellcey - Oct. 21, 2011, 8:50 p.m.
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

Patch

--- 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.  */