From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30072 invoked by alias); 11 Aug 2017 09:27:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 30044 invoked by uid 89); 11 Aug 2017 09:27:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:static., HContent-Transfer-Encoding:8bit X-HELO: mail-io0-f174.google.com Received: from mail-io0-f174.google.com (HELO mail-io0-f174.google.com) (209.85.223.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Aug 2017 09:27:14 +0000 Received: by mail-io0-f174.google.com with SMTP id j32so18334664iod.0 for ; Fri, 11 Aug 2017 02:27:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=fQp2KkI35o09FZL5VHTtUDzFzY5YNuR1FfpaUBabr9w=; b=Hu2IhlL37+6+y84b6sBoZY9VbaVH4cF7Y+4eIdOOw+ZVtAUDhdOtzApxYW4GRGbS38 h/4uTtK78gGwos1ag+cz6C2aV4uxe5HA8RUPasYwcqh2UpxnAzc3fJ+Hqv8pYqj7EHwp epKWbSaa+H+cW662CPeHcNR16XHT2guNi6kuFifGtdg5f4gjlCfYt9LNaaPEUhlp3GOS A1pIm5vmH4qAReLEFJ6+L1h+IiRO8gEVmuI5ho986ZNGkXI7D99czsAai99fZpE7RnpZ /hG5jhRXnHl4VKkZ3ZNuxaa/5eC/lO8UhWwlEca4H8S1XDH+5vQlbqEpHiu7ehyhpq3L M11A== X-Gm-Message-State: AHYfb5jymTPr6SzggfpXZNTAs4EgX8YCp90kdQ23MiPGmjj+uSx2i6+c MUbKBFKulZRwOg== X-Received: by 10.107.12.197 with SMTP id 66mr12306639iom.273.1502443632646; Fri, 11 Aug 2017 02:27:12 -0700 (PDT) Received: from 1170ee0b50d5 (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id i13sm196737ioo.48.2017.08.11.02.27.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 02:27:12 -0700 (PDT) Date: Fri, 11 Aug 2017 09:27:00 -0000 From: Yao Qi To: Alex Lindsay Cc: gdb-patches@sourceware.org Subject: Re: Synthetic symbol leak in in elf_x86_64_get_synthetic_symtab and elf_read_minimal_symbols Message-ID: <20170811092709.GH8039@1170ee0b50d5> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00227.txt.bz2 On 17-08-07 10:19:15, Alex Lindsay wrote: > > We perform a couple of dynamic allocations in > elf_x86_64_get_synthetic_symtab (elf64-x86-64.c): > > s = *ret = (asymbol *) bfd_zmalloc (size); > > names = (char *) bfd_malloc (size); > > that appear to never get freed. My patch for this: Good catch! It is more complicated that other bfd targets allocate memory for asymbol in a different way as if asymbol.name is defined as an zero-length array, so memory allocated for both asymbol and .name in one bfd_malloc call, like, sym = *r->sym_ptr_ptr; if (!sym_exists_at (syms, opdsymend, symcount, sym->section->id, sym->value + r->addend)) { ++count; size += sizeof (asymbol); size += strlen (syms[i]->name) + 2; } } if (size == 0) goto done; s = *ret = bfd_malloc (size); or size = count * sizeof (asymbol); p = relplt->relocation; for (i = 0; i < count; i++, p += elf32_arm_size_info.int_rels_per_ext_rel) { size += strlen ((*p->sym_ptr_ptr)->name) + sizeof ("@plt"); if (p->addend != 0) size += sizeof ("+0x") - 1 + 8; } s = *ret = (asymbol *) bfd_malloc (size); > > diff --git a/gdb/elfread.c b/gdb/elfread.c > index ece704ca7c..5ed8a6f957 100644 > --- a/gdb/elfread.c > +++ b/gdb/elfread.c > @@ -1144,6 +1144,9 @@ elf_read_minimal_symbols (struct objfile *objfile, int > symfile_flags, > > if (symtab_create_debug) > fprintf_unfiltered (gdb_stdlog, "Done reading minimal symbols.\n"); > + if (synthcount > 0) > + xfree ((char *) synthsyms->name); We can't do this for some bfd targets. > + xfree (synthsyms); We can only safely do this, but .name is leaked for x86_64. Other tools using bfd, like objdump, nm, and gprof may have this issue too. I'll ask binutils people on asymbol allocation and de-allocation. -- Yao (齐尧)