> > "ggc_collect() discarding/reusing remap_debug_filename() output, thus > > producing invalid objects" > > Hmm, but AFAICS it can end up on the heap if plain get_src_pwd () result > survives. I vaguely remember GC being happy with heap strings (due to > identifiers?), but not sure. Otherwise the patch looks obvious enough.
Good point, remap_filename can return the original filename pointer (which can point to env["PWD"] or to an allocated string) or a ggc string. Since not freeing the string pointed to by a static variable is ok (as getpwd does it), what about checking if remap_filename just returns the input filename ptr again, and if not copy the ggc string into an allocated buffer. > How did you test it? With a file which compiled with -fdebug-prefix-map=src=OBJ and -O2 contains a different string than OBJ, such as "SR.7568". When removing a function from the file it changes to e.g. "*.LC609", this is deterministic. These new strings were written into a pointer (= *comp_dir_string_cache) returned by ggc_alloc_atomic(). Disabling ggc_collect() solves it, as does this patch. Otherwise this was hard to reproduce, the file has to be large enough and not compiling with -O2 or even adding additional debug code made it disappear or at least unreproducible. > The patch misses a changelog entry. Will add one.
