This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/17437] [4.0 Regression] obscure GC problem
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Sep 2004 19:48:31 -0000
- Subject: [Bug other/17437] [4.0 Regression] obscure GC problem
- References: <20040912151302.17437.steven@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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