help debug hash_map garbage collection issue

[Jason Merrill]

On Tue, Apr 20, 2021 at 8:31 PM Martin Sebor via Gcc <gcc@gcc.gnu.org> wrote:
>
> On 4/20/21 5:03 PM, Martin Sebor wrote:
> > On 4/20/21 4:15 PM, Martin Sebor wrote:
> >> On 4/20/21 2:36 PM, Martin Sebor wrote:
> >>> On 4/20/21 2:13 PM, Marek Polacek wrote:
> >>>> On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote:
> >>>>> I have a static hash_map object that needs to persist across passes:
> >>>>>
> >>>>>    static GTY(()) hash_map<tree, bitmap> *map;
> >>>>>
> >>>>> I initialize the map like so:
> >>>>>
> >>>>>    map = hash_map<tree, bitmap>::create_ggc (4);
> >>>>>
> >>>>> But I see crashes when accessing the map after adding and removing
> >>>>> some number of entries in a few passes.  The crashes are due to
> >>>>> the map having been garbage-collected and the memory allocated to
> >>>>> it poisoned (it has the 0xa5a5a5a5a5a5a5a5 bit pattern that I see
> >>>>> in GDD being written into the map by poison_pages()).
> >>>>>
> >>>>> I assumed marking the map pointer GTY(()) would keep the garbage
> >>>>> collector from touching the map.  Is there something else I need
> >>>>> to do to keep it from doing that?
> >>>>>
> >>>>> Thanks
> >>>>> Martin
> >>>>>
> >>>>> PS Just in case it matters, the bitmap in the table is allocated
> >>>>> via BITMAP_ALLOC() with a bitmap_obstack variable defined alongside
> >>>>> the map.
> >>>>
> >>>> My sense is that this is the problem.  What happens if you use
> >>>> BITMAP_GGC_ALLOC?
> >>>
> >>> Same thing :(
> >>
> >> I reduced the problem to the following patch/test case no involving
> >> a bitmap or other pointers.  With it applied, GCC reliably crashes.
> >> An example of a stack trace is below the patch.  What am I missing?
> >
> > It seems that assigning the address of an object allocated by
> > ggc_alloc() (which presumably includes BITMAP_GGC_ALLOC()) to
> > a GTY-marked pointer "defeats" the purpose of the marker and
> > allows it to be garbage collected.
>
> But this is not true.  There are plenty of counterexamples, including
> in tree.c which defines several GTY hash_tables (but no maps).  I tried
> moving the test case below from gimple.c to tree.c but there it doesn't
> even compile.  I get this error (and a couple of others):
>
> In file included from /src/gcc/master/gcc/tree.c:16179:
> ./gt-tree.h: In function ‘void gt_ggc_mx(int_hash<int, 0, 2147483647>&)’:
> ./gt-tree.h:156:21: error: no matching function for call to
> ‘gt_ggc_mx(int_hash<int, 0, 2147483647>*)’
>     gt_ggc_mx (&((*x)));
>                       ^
> So as another experiment I moved it builtins.c where it does compile
> (go figure) but then it crashes when I call it the same way from
> c_strlen().

This is because tree.c is in GTFILES, while gimple.c and tree.c are
not, so gengtype never sees the GTY decoration in the latter files.

I don't know why when it does see the GTY, it ends up trying to mark
an int_hash*.

Jason