Re: [RFC, PATCH] Fix GC crash related to free PHI nodes

[Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>]

Jeff Law wrote:

> On Thu, 2004-09-16 at 15:17, Ulrich Weigand wrote:
> > Specifically, the garbage collector walks through the following
> > chain of references:
> > 
> > - the ssa_names varray
> > - a SSA_NAME in the array
> > - a MODIFY_EXPR chained off the SSA_NAME (via TREE_CHAIN)
> > - a STMT_ANN annotation hanging off the MODIFY_EXPR
> > - a dataflow structure hanging off the annotation
> > - a PHI node present as immediate use in the df structure
> >   (note that this PHI node is on the free_phinodes list)
> Well, the first thing I would ask is whether or not the SSA_NAME
> is marked as being in the free list...  There may be other instances
> of the problem I fixed earlier this week lying around.  

This SSA_NAME is *not* marked as in-free-list.

> What's not clear to me is where/how we had DF information
> attached to the PHI node's annotation at the point where we
> called thread_jumps.  

Just to clarify: The DF information is not attached to the PHI's
annotation, it is attached to the MODIFY_EXPR stmt that hangs off
the SSA_NAME.  It *points* to the PHI node, though.

> Any chance you could get me a backtrace
> at the point where you need to call redirect_immediate_uses
> to ponder?

#0  release_phi_node (phi=0x20000a76c00) at ../../gcc-head/gcc/tree-phinodes.c:228
#1  0x00000000801c3342 in add_phi_arg (phi=0x3ffffffeb30, def=0x20000a729d8, e=0x20000a393a8) at ../../gcc-head/gcc/tree-phinodes.c:344
#2  0x00000000800eee76 in thread_jumps () at ../../gcc-head/gcc/tree-cfg.c:3947
#3  0x00000000800d7358 in cleanup_tree_cfg () at ../../gcc-head/gcc/tree-cfg.c:725
#4  0x00000000801d641e in tree_ssa_loop_done () at ../../gcc-head/gcc/tree-ssa-loop.c:351
#5  0x000000008010c24e in execute_one_pass (pass=0x8087a360) at ../../gcc-head/gcc/tree-optimize.c:501
#6  0x000000008010c3b8 in execute_pass_list (pass=0x8087a360) at ../../gcc-head/gcc/tree-optimize.c:536
#7  0x000000008010c3ea in execute_pass_list (pass=0x8087a120) at ../../gcc-head/gcc/tree-optimize.c:537
#8  0x000000008010c3ea in execute_pass_list (pass=0x808799d0) at ../../gcc-head/gcc/tree-optimize.c:537
#9  0x000000008010c752 in tree_rest_of_compilation (fndecl=0x200006ede00, nested_p=0 '\0') at ../../gcc-head/gcc/tree-optimize.c:618
#10 0x00000000800348d6 in c_expand_body (fndecl=0x200006ede00) at ../../gcc-head/gcc/c-decl.c:6428
#11 0x00000000806390b0 in cgraph_expand_function (node=0x20000759460) at ../../gcc-head/gcc/cgraphunit.c:814
#12 0x000000008063c198 in cgraph_expand_all_functions () at ../../gcc-head/gcc/cgraphunit.c:1680
#13 0x000000008063c600 in cgraph_optimize () at ../../gcc-head/gcc/cgraphunit.c:1770
#14 0x00000000800371e0 in c_write_global_declarations () at ../../gcc-head/gcc/c-decl.c:7015
#15 0x000000008058bfaa in compile_file () at ../../gcc-head/gcc/toplev.c:1004
#16 0x000000008058ec6a in do_compile () at ../../gcc-head/gcc/toplev.c:2096
#17 0x000000008058ed12 in toplev_main (argc=13, argv=0x3fffffff948) at ../../gcc-head/gcc/toplev.c:2128
#18 0x00000000800cc4e2 in main (argc=13, argv=0x3fffffff948) at ../../gcc-head/gcc/main.c:35

Now, investigating further, the immediate use in question is generated here:

#0  add_immediate_use (stmt=0x200007615a0, use_stmt=0x20000a76c00) at ../../gcc-head/gcc/tree-dfa.c:330
#1  0x00000000800f48ca in compute_immediate_uses_for_phi (phi=0x20000a76c00, calc_for=0x8019c9c4 <need_imm_uses_for>)
    at ../../gcc-head/gcc/tree-dfa.c:268
#2  0x00000000800f3fee in compute_immediate_uses (flags=2, calc_for=0x8019c9c4 <need_imm_uses_for>) at ../../gcc-head/gcc/tree-dfa.c:176
#3  0x000000008019e13a in tree_ssa_dse () at ../../gcc-head/gcc/tree-ssa-dse.c:394
#4  0x000000008010c272 in execute_one_pass (pass=0x80879e98) at ../../gcc-head/gcc/tree-optimize.c:501
#5  0x000000008010c3dc in execute_pass_list (pass=0x80879e98) at ../../gcc-head/gcc/tree-optimize.c:536
#6  0x000000008010c40e in execute_pass_list (pass=0x808799d0) at ../../gcc-head/gcc/tree-optimize.c:537
#7  0x000000008010c776 in tree_rest_of_compilation (fndecl=0x200006ede00, nested_p=0 '\0') at ../../gcc-head/gcc/tree-optimize.c:618
#8  0x00000000800348d6 in c_expand_body (fndecl=0x200006ede00) at ../../gcc-head/gcc/c-decl.c:6428
#9  0x00000000806390d4 in cgraph_expand_function (node=0x20000759460) at ../../gcc-head/gcc/cgraphunit.c:814
#10 0x000000008063c1bc in cgraph_expand_all_functions () at ../../gcc-head/gcc/cgraphunit.c:1680
#11 0x000000008063c624 in cgraph_optimize () at ../../gcc-head/gcc/cgraphunit.c:1770
#12 0x00000000800371e0 in c_write_global_declarations () at ../../gcc-head/gcc/c-decl.c:7015
#13 0x000000008058bfce in compile_file () at ../../gcc-head/gcc/toplev.c:1004
#14 0x000000008058ec8e in do_compile () at ../../gcc-head/gcc/toplev.c:2096
#15 0x000000008058ed36 in toplev_main (argc=13, argv=0x3fffffff948) at ../../gcc-head/gcc/toplev.c:2128
#16 0x00000000800cc4e2 in main (argc=13, argv=0x3fffffff948) at ../../gcc-head/gcc/main.c:35

... and it is not cleaned up by the free_df call following later in tree_ssa_dse.


This does look like just the problem you've fixed in:
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01511.html

And indeed after applying that patch, the segfault goes away ...


Sorry for wasting your time with an already solved problem; your
fix hadn't been part of my tree yet (I didn't want to update
before I understood the problem, as it appeared to be easily
masked by unrelated code changes -- and I hadn't noticed your
patch until now ...).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de