Help with bug in GCC garbage collector

[Steve Ellcey <sellcey@marvell.com>]

I was wondering if anyone could help me investigate a bug I am seeing
in the GCC garbage collector.  This bug (which may or may not be PR
89179) is causing a segfault in GCC, but when I try to create a
preprocessed source file, the bug doesn't trigger.  The problem is with
the garbage collector trying to mark some memory that has already been
freed.  I have tracked down the initial allocation to:

symbol_table::allocate_cgraph_symbol

It has:

	node = ggc_cleared_alloc<cgraph_node> ();

to allocate a cgraph node.  With the GGC debugging on I see this
allocated:

	Allocating object, requested size=360, actual=360 at 0xffff7029c210 on 0x41b148c0

then freed:

	Freeing object, actual size=360, at 0xffff7029c210 on 0x41b148c0

And then later, while the garbage collector is marking nodes, I see:

	Marking 0xffff7029c210

The garbage collector shouldn't be marking this node if has already
been freed.

So I guess my main question is how do I figure out how the garbage
collector got to this memory location?  I am guessing some GTY pointer
is still pointing to it and hadn't got nulled out when the memory was
freed.  Does that seem like the most likely cause?

I am not sure why I am only running into this with one particular
application on my Aarch64 platform.  I am building it with -fopenmp,
which could have something to do with it (though there are no simd functions in the application).  The application is not that large as C++ programs go.

Steve Ellcey
sellcey@marvell.com