ggc_collect() discarding/reusing remap_debug_filename() output, thus producing invalid objects

[Otto, Thomas]

Hi,

I am observing a memory error with gcc 8.3: Compiling a large C++ file 
(~8000 lines) with -fdebug-prefix-map=/user/path/obj=../obj and 
-gsplit-dwarf results in an object which does not store the specified 
"../obj" but a string like "SR.7568".

This seems to be related to the ggc garbage collector, a quick test 
making ggc_collect() a no-op solves the problem.

The corruption shows up in comp_dir_string() [dwarf2out.c: 20702]. 
There the `static const char* cached_wd` is first set to the correct "../obj".
This string is returned from remap_debug_filename() [file-prefix-map.c:129] 
which in turn was allocated by ggc_alloc_atomic().

When comp_dir_string() is called again the cached string is corrupted. In one 
case I could trace this back to ht_lookup_with_hash() / table->alloc_subobject() 
[libcpp/symtab.c:163]. There table->alloc_subobject is set to 
stringpool_ggc_alloc() which is a wrapper for ggc_alloc_atomic(). This returned 
the same address as was stored in `cached_wd`, resulting in "../obj" changing 
to "SR.7568".

I tried to annotate `cached_wd` via GTY((..)) as on first glance it seems 
the gc mistakenly re-uses it, but the `gengtype` generated state file never 
picks this variable up.

The annoying part is that this bug is hard to reproduce, most other input 
files do not trigger it and even adding debug code or not compiling with -O2 
make it disappear sometimes. Explicitly calling
 `ggc_force_collect = true; ggc_collect();  ggc_force_collect = false;` right 
after setting cached_wd does not trigger it. However gcc 8.2 and 8.1 
built with the same setup (gcc 4.9.3) also show this problem.

Can someone with more gc experience look at this and decide if this is an 
actual bug? Otherwise I would just point cached_wd to non-gc memory and 
store the value there, but maybe I stumbled on a rare yet brittle corner case.


Thanks & Regards

Thomas