From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59808 invoked by alias); 11 Aug 2017 21:20:38 -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 59797 invoked by uid 89); 11 Aug 2017 21:20:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=definite X-HELO: mail-it0-f65.google.com Received: from mail-it0-f65.google.com (HELO mail-it0-f65.google.com) (209.85.214.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Aug 2017 21:20:36 +0000 Received: by mail-it0-f65.google.com with SMTP id r9so4457131ita.3 for ; Fri, 11 Aug 2017 14:20:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=6pyUYbSaEKOa92QpdQkJv88acAGtfkgvxja78xA281A=; b=s7nghKrQw7VjXjleh5zStSLMMT2H7nJ0udxUWHGP39zh433mesgax1J/BQfqnjWYbj xHKjnIBQSimbAumfmfIyH8gMtOoacDypwndJlu42hUyXGiLJZZZ+9bTjYZvLad5xwi9E hD4qzMjdSq9D5spMknuwstO7Mzb2I51COr68klcyjYWa28q3K0DG3GZ/Hs0Hbs7C1AIM jcPq7OD/TPpkHMm/rnKUi8xW7M+xYdPp/KD00AHE7NL+r87IPz6phxaxf1JXni4YEZKt Z1PPlLa2neOZfcAGSX9DZNqZMIVNp1lf+hAab9ZtJPlxkkqX1v926Qn3Nl/YW5GGjlCF j3JQ== X-Gm-Message-State: AHYfb5hEvFP8fw2IHLUQAIw3Tf4N63BP/lVrV4cCMI35+XQubquMubv9 na5QfInD/ZUyaing674= X-Received: by 10.36.85.151 with SMTP id e145mr45771itb.106.1502486434414; Fri, 11 Aug 2017 14:20:34 -0700 (PDT) Received: from [128.174.163.204] ([128.174.163.204]) by smtp.gmail.com with ESMTPSA id z140sm41262itb.30.2017.08.11.14.20.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 14:20:33 -0700 (PDT) Subject: Re: Synthetic symbol leak in in elf_x86_64_get_synthetic_symtab and elf_read_minimal_symbols To: "H.J. Lu" , Yao Qi Cc: GDB References: <20170811092709.GH8039@1170ee0b50d5> <20170811154542.GK8039@1170ee0b50d5> From: Alex Lindsay Message-ID: Date: Fri, 11 Aug 2017 21:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00257.txt.bz2 I can verify that the objdump example is fixed in HEAD, but I still get this leak with `valgrind --leak-check=full --show-leak-kinds=definite gdb ./hello`: ==18127== 300,438 bytes in 5 blocks are definitely lost in loss record 11,404 of 11,407 ==18127== at 0x4C2DE31: malloc (vg_replace_malloc.c:299) ==18127== by 0x62F747: bfd_malloc (libbfd.c:193) ==18127== by 0x62F941: bfd_zmalloc (libbfd.c:278) ==18127== by 0x649E14: elf_x86_64_get_synthetic_symtab (elf64-x86-64.c:6835) ==18127== by 0x2F1B9E: elf_read_minimal_symbols(objfile*, int, elfinfo const*) (elfread.c:1124) ==18127== by 0x2F1D7C: elf_symfile_read(objfile*, enum_flags) (elfread.c:1182) ==18127== by 0x563738: read_symbols(objfile*, enum_flags) (symfile.c:861) ==18127== by 0x563E55: syms_from_objfile_1(objfile*, section_addr_info*, enum_flags) (symfile.c:1062) ==18127== by 0x563EAC: syms_from_objfile(objfile*, section_addr_info*, enum_flags) (symfile.c:1078) ==18127== by 0x5641F7: symbol_file_add_with_addrs(bfd*, char const*, enum_flags, section_addr_info*, enum_flags, objfile*) (symfile.c:1177) ==18127== by 0x5644C1: symbol_file_add_from_bfd(bfd*, char const*, enum_flags, section_addr_info*, enum_flags, objfile*) (symfile.c:1268) ==18127== by 0x547B32: solib_read_symbols(so_list*, enum_flags) (solib.c:707) On 08/11/2017 11:44 AM, H.J. Lu wrote: > On Fri, Aug 11, 2017 at 8:45 AM, Yao Qi wrote: >> On 17-08-11 08:30:21, H.J. Lu wrote: >>>> 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. >>>> >>> This is: >>> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=21943 >>> >> I opened it :) >> >>> i386 and x86-64 get_synthetic_symtab don't know if @plt should >>> be added to symbol name for a PLT entry. The first pass checks >>> if @plt is needed and extra space is allocated in the second pass. >>> We can assume @plt is needed and waste some space if it isn't. >> Do you plan to fix it? >> > Done. >