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
