[Bug other/17437] New: obscure GC problem

[Bug other/17437] New: obscure GC problem

[steven at gcc dot gnu dot org]

Compile the attached test case with -O3 and you get this: 
Program received signal SIGSEGV, Segmentation fault. 
0x000000000090e182 in lookup_page_table_entry (p=0x14) at ../../mainline/gcc/
ggc-page.c:581 
581       while (table->high_bits != high_bits) 
 
 
$ ../build/gcc/xgcc -c -B../build/gcc/ -O3 -v t.i 
Reading specs from ../build/gcc/specs 
Configured with: ../mainline/configure --disable-nls --disable-multilib 
--disable-libmudflap --enable-languages=c 
Thread model: posix 
gcc version 4.0.0 20040912 (experimental) 
 ../build/gcc/cc1 -fpreprocessed t.i -quiet -dumpbase t.i -mtune=k8 -auxbase t 
-O3 -version -o /tmp/ccpw2dgs.s 
GNU C version 4.0.0 20040912 (experimental) (x86_64-unknown-linux-gnu) 
        compiled by GNU C version 3.3.3 (SuSE Linux). 
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 
t.i: In function `live_out_1': 
t.i:14236: internal compiler error: Segmentation fault 
 
Of course, I don't have a smaller test case, and the bug does not reproduce 
with a gcac enabled compiler.  GC problems, *sigh*.

-- 
           Summary: obscure GC problem
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: steven at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] obscure GC problem

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-09-12 15:14 -------
Created an attachment (id=7106)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7106&action=view)
Test case for this bug


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

Re: [Bug other/17437] New: obscure GC problem

[Graham Stott]

Steven,

FWIW it doesn't fail on a x86-ia64 cross using normal -O2 opts

But I could trigger a failure, but not your failure using  -O3 -fno-unit-at_a-time

t.i:16476: error: Inlined_to pointer is wrong
detect_webs_set_in_cond_jump/314: (inline copy in build_i_graph/312) 54 insns tree inlinable
   called by: make_webs/313 (inlined)
   calls:
t.i:16476: internal compiler error: verify_cgraph_node failed.

Graham

[Bug other/17437] obscure GC problem

[graham dot stott at btinternet dot com]

------- Additional Comments From graham dot stott at btinternet dot com  2004-09-12 17:30 -------
Subject: Re:  New: obscure GC problem

Steven,

FWIW it doesn't fail on a x86-ia64 cross using normal -O2 opts

But I could trigger a failure, but not your failure using  -O3 -fno-unit-at_a-time

t.i:16476: error: Inlined_to pointer is wrong
detect_webs_set_in_cond_jump/314: (inline copy in build_i_graph/312) 54 insns tree inlinable
   called by: make_webs/313 (inlined)
   calls:
t.i:16476: internal compiler error: verify_cgraph_node failed.

Graham


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] obscure GC problem

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-12 17:34 -------
Now the non-unit-at-a-time problems is most likely PR 17419.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical
            Summary|obscure GC problem          |[4.0 Regression] obscure GC
                   |                            |problem
   Target Milestone|---                         |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-14 05:36 -------
I think the message at <http://gcc.gnu.org/ml/gcc/2004-09/msg00823.html> is the same bug.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-09-14 06:23 -------
Jeff, the bug you described in your main at 
<http://gcc.gnu.org/ml/gcc/2004-09/msg00823.html> 
is exactly like what I've observed. 
 
I couldn't find any place where we fail do free_df, 
but I haven't looked very closely at it yet. 
 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-09-14 06:23:35
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[stevenb at suse dot de]

------- Additional Comments From stevenb at suse dot de  2004-09-14 06:25 -------
Subject: Re:  [4.0 Regression] obscure GC problem

On Tuesday 14 September 2004 07:36, pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-14
> 05:36 ------- I think the message at
> <http://gcc.gnu.org/ml/gcc/2004-09/msg00823.html> is the same bug.

That certainly looks like the bug I've been seeing.

Gr.
Steven



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2004-09-14 15:31 -------
Subject: Re:  [4.0 Regression] obscure GC problem

On Tue, 2004-09-14 at 00:23, steven at gcc dot gnu dot org wrote:
> ------- Additional Comments From steven at gcc dot gnu dot org  2004-09-14 06:23 -------
> Jeff, the bug you described in your main at 
> <http://gcc.gnu.org/ml/gcc/2004-09/msg00823.html> 
> is exactly like what I've observed. 
>  
> I couldn't find any place where we fail do free_df, 
> but I haven't looked very closely at it yet. 
I wonder if free_df is unable to free dataflow information attached
to statements that have been deleted or something similar.

What doesn't make sense to me is that the dataflow information isn't
attached to SSA_NAMEs, it's attached to statement nodes and PHIs.
So at least that part of my analysis is faulty.

Hmm, I wonder if something has mucked up the type of the annotation
or something similar.

Diego, can you dump the annotation in frame 5 from your failure?
It would also be useful to dump the lang tree node in frame 6.
You may have to do these by hand somewhat since I don't think we have
a pretty printer for annotations and lang tree nodes.

Jeff 



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[dnovillo at redhat dot com]

------- Additional Comments From dnovillo at redhat dot com  2004-09-14 19:07 -------
Subject: Re:  [4.0 Regression] obscure GC problem

On Tue, 2004-09-14 at 11:31, Jeffrey A Law wrote:

> What doesn't make sense to me is that the dataflow information isn't
> attached to SSA_NAMEs, it's attached to statement nodes and PHIs.
> So at least that part of my analysis is faulty.
> 
Because SSA_NAMEs store their defining statement in tree.common.chain
and gt_ggc_mx_lang_tree_node jumps from the SSA_NAME into its defining
statement.  From there, we start traversing the statement's DU chains
and end up in a statement whose basic block has been ggc_free'd already
by cfg.c:expunge_block.

This allows me to go past this failure and go into stage3, but I think
the real issue may be that somebody is holding on to DU chains too long.

I don't know what the right approach would be here.  Force people to
always flush out DU chains?  Maybe.  But then, why put these things on
GC memory to begin with?


Diego.

Index: cfg.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cfg.c,v
retrieving revision 1.65
diff -d -u -p -r1.65 cfg.c
--- cfg.c       7 Sep 2004 15:46:46 -0000       1.65
+++ cfg.c       14 Sep 2004 19:03:02 -0000
@@ -266,7 +266,6 @@ expunge_block (basic_block b)
   unlink_block (b);
   BASIC_BLOCK (b->index) = NULL;
   n_basic_blocks--;
-  ggc_free (b);
 }

 /* Create an edge connecting SRC and DEST with flags FLAGS.  Return newly




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2004-09-14 19:19 -------
Subject: Re:  [4.0 Regression] obscure GC problem

On Tue, 2004-09-14 at 13:07, Diego Novillo wrote:
> On Tue, 2004-09-14 at 11:31, Jeffrey A Law wrote:
> 
> > What doesn't make sense to me is that the dataflow information isn't
> > attached to SSA_NAMEs, it's attached to statement nodes and PHIs.
> > So at least that part of my analysis is faulty.
> > 
> Because SSA_NAMEs store their defining statement in tree.common.chain
> and gt_ggc_mx_lang_tree_node jumps from the SSA_NAME into its defining
> statement.  From there, we start traversing the statement's DU chains
> and end up in a statement whose basic block has been ggc_free'd already
> by cfg.c:expunge_block.
Which is part of the reason why I think sprinkling ggc_free calls
around is generally a bad idea.  While we may think we know the
lifetime of some object, it's bloody easy to miss some pointer
pointing into the object keeping it live.


> 
> This allows me to go past this failure and go into stage3, but I think
> the real issue may be that somebody is holding on to DU chains too long.
Agreed.

> I don't know what the right approach would be here.  Force people to
> always flush out DU chains?  Maybe.  But then, why put these things on
> GC memory to begin with?
Well, IMHO the ggc_free is bogus and we need to fix whatever code
forgot to call free_df.

jeff




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2004-09-14 19:48 -------
Subject: Re:  [4.0 Regression] obscure GC problem

On Tue, 2004-09-14 at 13:07, dnovillo at redhat dot com wrote:
> ------- Additional Comments From dnovillo at redhat dot com  2004-09-14 19:07 -------
> Subject: Re:  [4.0 Regression] obscure GC problem
> 
> On Tue, 2004-09-14 at 11:31, Jeffrey A Law wrote:
> 
> > What doesn't make sense to me is that the dataflow information isn't
> > attached to SSA_NAMEs, it's attached to statement nodes and PHIs.
> > So at least that part of my analysis is faulty.
> > 
> Because SSA_NAMEs store their defining statement in tree.common.chain
> and gt_ggc_mx_lang_tree_node jumps from the SSA_NAME into its defining
> statement.  From there, we start traversing the statement's DU chains
> and end up in a statement whose basic block has been ggc_free'd already
> by cfg.c:expunge_block.
> 
> This allows me to go past this failure and go into stage3, but I think
> the real issue may be that somebody is holding on to DU chains too long.
> 
> I don't know what the right approach would be here.  Force people to
> always flush out DU chains?  Maybe.  But then, why put these things on
> GC memory to begin with?
BTW, I have a theory why this is happening (dangling dataflow
information).

The code to remove dataflow walks through the IL removing dataflow
information on every statement it finds.


So imagine if we had dataflow information attached to a statement
which we delete.   Furthermore, assume that statement is in a
block which we ultimately delete.  ANd (of course) we're assuming
that the statement with the attached dataflow information has a
SSA_NAME in the SSA_NAME table, but assume the SSA_NAME hasn't
been released.


I _think_ that could lead to the behavior we're seeing and would
match the preliminary stuff I've seen under GDB.

jeff




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-15 04:31 -------
Does the patch at <http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01511.html> fix this problem?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-12 13:03 -------
Can you try this again?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[stevenb at novell dot com]

------- Additional Comments From stevenb at novell dot com  2004-10-14 16:09 -------
Subject: Re:  [4.0 Regression] obscure GC problem

On Tuesday 12 October 2004 15:03, pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-12
> 13:03 ------- Can you try this again?

Can't reproduce it



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437

[Bug other/17437] [4.0 Regression] obscure GC problem

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-14 16:30 -------
So closing as fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437