On Wed, Mar 20, 2019 at 2:44 PM Otto, Thomas <thomas.o...@pdv-fs.de> wrote > > > > "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.
I think we always want GC allocated storage here since the whole dwarf2out data structures live in GC memory. That means unconditionally copying there as is done inside the DWARF2_DIR_SHOULD_END_WITH_SEPARATOR path. > > 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. >
