On Tue, Jul 26, 2011 at 10:38:09PM +0200, Jakub Jelinek wrote:
> With that I've discovered that lookup_filename assumes that the string
> it is called in is kept around, as it stores just the pointer and not a copy
> of that string. It seems all other places that call lookup_filename already
> call it with somehow persistent string and before my .debug_macro patch so
> did output_macinfo, because it never freed the malloced strings.
> The reason I've added the freeing was that I sometimes reuse the pointers
> for something else (the transparent_include group names) and valgrind etc.
> would be unhappy about unreachable malloced blocks not being freed, albeit
> so close to the end of the compilation.
> Instead of copying the string always the following patch just copies it
> if it stored that pointer (first hunk).
Forgot to add, what this newly introduced bug caused was that when using
.file/.loc directives if the same file was included more than once the
second and following copy often wouldn't share the same .file number
with the older one and thus .debug_line grew unnecessarily. And, it could
rarely happen that it would use a wrong file name table index too, if the
freed memory contained something that would match some filename. And of
course could crash as any reads from freed memory.
Jakub
