This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Multiple apparent leaks in dwarf2.c


With the following:

#include <bfd.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
        bfd * b;
        long f;
        void *syms;
        size_t size;
        asymbol **as;
        const char *file;
        const char *func;
        int line;

        if (argc < 2) {
                printf("usage: valbfd <file>\n");
                exit(1);
        }

        if (!(b = bfd_openr(argv[1], NULL))) {
                printf("failed to open %s.\n", argv[1]);
                exit(1);
        }

        if (!bfd_check_format_matches(b, bfd_object, NULL)) {
                printf("no match.\n");
                exit(1);
        }

        if (!(bfd_get_file_flags(b) & HAS_SYMS)) {
                printf("no syms.\n");
                exit(1);
        }

        size = bfd_get_symtab_upper_bound(b);
        syms = malloc(size);
        as = syms;
        bfd_canonicalize_symtab(b, syms);
        bfd_find_nearest_line(b, (*as)->section, as, 4000000, &file, &func, &line);
        bfd_close(b);
        free(syms);
}

valgrind tells us:

==15031== 18577 bytes in 1 blocks are definitely lost in loss record 1 of 4
==15031==    at 0x1B903534: malloc (vg_replace_malloc.c:130)
==15031==    by 0x8049790: bfd_malloc (libbfd.c:152)
==15031==    by 0x808CE7E: bfd_simple_get_relocated_section_contents (simple.c:150)
==15031==    by 0x808B75F: read_abbrevs (dwarf2.c:447)
==15031==    by 0x808C77A: parse_comp_unit (dwarf2.c:1483)
==15031==    by 0x808CB76: _bfd_dwarf2_find_nearest_line (dwarf2.c:1832)
==15031==    by 0x805D324: _bfd_elf_find_nearest_line (elf.c:6111)
==15031==    by 0x8049281: main (valbfd.c:40)
==15031==
==15031==
==15031== 43184 bytes in 619 blocks are definitely lost in loss record 2 of 4
==15031==    at 0x1B903F5A: realloc (vg_replace_malloc.c:196)
==15031==    by 0x80497D0: bfd_realloc (libbfd.c:175)
==15031==    by 0x808B679: read_abbrevs (dwarf2.c:495)
==15031==    by 0x808C77A: parse_comp_unit (dwarf2.c:1483)
==15031==    by 0x808CB76: _bfd_dwarf2_find_nearest_line (dwarf2.c:1832)
==15031==    by 0x805D324: _bfd_elf_find_nearest_line (elf.c:6111)
==15031==    by 0x8049281: main (valbfd.c:40)
==15031==
==15031==
==15031== 48831 (23816 direct, 25015 indirect) bytes in 742 blocks are definitely lost in loss record 3 of 4
==15031==    at 0x1B903534: malloc (vg_replace_malloc.c:130)
==15031==    by 0x8049800: bfd_realloc (libbfd.c:173)
==15031==    by 0x808B679: read_abbrevs (dwarf2.c:495)
==15031==    by 0x808C77A: parse_comp_unit (dwarf2.c:1483)
==15031==    by 0x808CB76: _bfd_dwarf2_find_nearest_line (dwarf2.c:1832)
==15031==    by 0x805D324: _bfd_elf_find_nearest_line (elf.c:6111)
==15031==    by 0x8049281: main (valbfd.c:40)

These appear to indeed be valid leaks: the code is using the
non-objalloc'd bfd_realloc/bfd_malloc routines, but there's nothing to
clear up the debug info stash that I can see (binutils 2.15).

Using an earlier binutils, there was also leaks in decode_line_info()
centering around concat_filename(). These appear to have been mostly
fixed, though code inspection shows some obvious error path leaks:

   1058       char * filename = table->num_files ? concat_filename (table, 1) : NULL;
...
   1142                   bfd_set_error (bfd_error_bad_value);
   1143                   return 0;
...
   1125                       if (! table->files)
   1126                         return 0;
...
   1208       if (filename)
   1209         free (filename);

It's the other ones that are the big concern though: this is leaking 4Mb with
our application. Any chance of these getting fixed? I couldn't see a
particular reason that bfd_simple_get_relocated_section_contents()
wasn't allocating from abfd->memory, but I don't know what's best for
the realloc ones. Do we need some gunk in _bfd_elf_close_and_cleanup() ?

(I haven't looked hard at the source, so it's possible I've got things
wrong).

cheers,
john


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]