From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106335 invoked by alias); 7 Aug 2017 09:16:57 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 100204 invoked by uid 89); 7 Aug 2017 09:15:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=20159, yes!, H*r:sk:static. X-HELO: mail-io0-f181.google.com Received: from mail-io0-f181.google.com (HELO mail-io0-f181.google.com) (209.85.223.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Aug 2017 09:15:23 +0000 Received: by mail-io0-f181.google.com with SMTP id m88so720586iod.2 for ; Mon, 07 Aug 2017 02:15:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=TKlV9KEienLQu7qUFXkdUkbfwcqlQnt7/5SqgSeKZrE=; b=b5jBuq1WS5zMR517CMfeulelDDFgvEuXEPVPWmbxhg0YutfkpKaMtaTPrkFII3kqVQ Dwjjg6czUpCwoMZcZHWI7OuSGkrD75RqA8FCLsmGm37g9Gh6lrvgNsNG8fymbSJUVwmN IxRu/W3a83jn4bMstN9tB81icy/VUF6ts3P98CFqqkjnXMoN/6WBjG89WRSy6LqnhGzq 96o2ojDxK6VAdHKBBIznFrDwsPZAXvVP+k5MMJZxlxPMcZHlVdOfcWGGiWUpr1TfRYLP odT4nhzhROWKAAWARf5UEFSB2KDv1LGbzod8J9SCNcu04APK7+Fdl7hKlTF2Wb/i3abq sGXw== X-Gm-Message-State: AHYfb5hStNzc/WLUpBf05zkFzjtS1qWwR0u65eund+ZE5XuYCw9ccrWr ikEUxbtlVk3FmH03 X-Received: by 10.107.18.40 with SMTP id a40mr10550606ioj.282.1502097306154; Mon, 07 Aug 2017 02:15:06 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id 196sm3497659iou.50.2017.08.07.02.15.04 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 07 Aug 2017 02:15:05 -0700 (PDT) From: Yao Qi To: Alex Lindsay Cc: gdb@sourceware.org Subject: Re: Large memory usage by gdb References: <420b109c-1610-d687-ae9a-b172542fafca@gmail.com> <6f204cea-21bf-3f70-aa61-df02aeba8a24@gmail.com> Date: Mon, 07 Aug 2017 09:16:00 -0000 In-Reply-To: <6f204cea-21bf-3f70-aa61-df02aeba8a24@gmail.com> (Alex Lindsay's message of "Fri, 4 Aug 2017 16:43:23 -0500") Message-ID: <86mv7b20z2.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00013.txt.bz2 Alex Lindsay writes: > and new call-graph. So my question is, is what I'm doing valuable? I Oh, definitely yes! Thanks a lot for the investigation. > haven't done any profiling yet to see how these changes affect my real > use case where I'm debugging an executable with lots of shared > libraries. Nevertheless, these leaks do seem to be very real. I know > that GDB developers are way better programmers than I am, so the fact > that these leaks haven't been found yet makes me wonder whether they > matter in real use cases or not. I am using a gdb built from the git > repository (GNU gdb (GDB) 8.0.50.20170803-git). leaks are bugs, and we should fix them. I can find these leaks in valgrind too, =3D=3D21225=3D=3D 463 (336 direct, 127 indirect) bytes in 1 blocks are defi= nitely lost in loss record 10,770 of 10,949^M =3D=3D21225=3D=3D at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_m= emcheck-amd64-linux.so)^M =3D=3D21225=3D=3D by 0x6C6DA2: bfd_malloc (libbfd.c:193)^M =3D=3D21225=3D=3D by 0x6C6F4D: bfd_zmalloc (libbfd.c:278)^M =3D=3D21225=3D=3D by 0x6D252E: elf_x86_64_get_synthetic_symtab (elf64-x8= 6-64.c:6846)^M =3D=3D21225=3D=3D by 0x4B397A: elf_read_minimal_symbols (elfread.c:1124)= ^M =3D=3D21225=3D=3D by 0x4B397A: elf_symfile_read(objfile*, enum_flags) (elfread.c:1182)^M =3D=3D21225=3D=3D by 0x63AC94: read_symbols(objfile*, enum_flags) (symfile.c:861)^M =3D=3D21225=3D=3D by 0x63A773: syms_from_objfile_1 (symfile.c:1062) and =3D=3D21225=3D=3D 32 bytes in 1 blocks are definitely lost in loss record 6= ,063 of 10,949^M =3D=3D21225=3D=3D at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_m= emcheck-amd64-linux.so)^M =3D=3D21225=3D=3D by 0x4C2FDEF: realloc (in /usr/lib/valgrind/vgpreload_= memcheck-amd64-linux.so)^M =3D=3D21225=3D=3D by 0x76CB31: d_growable_string_resize (cp-demangle.c:3= 963)^M =3D=3D21225=3D=3D by 0x76CB31: d_growable_string_init (cp-demangle.c:394= 2)^M =3D=3D21225=3D=3D by 0x76CB31: cplus_demangle_print (cp-demangle.c:4308)= ^M =3D=3D21225=3D=3D by 0x4C9535: cp_comp_to_string(demangle_component*, in= t) (cp-name-parser.y:1972)^M =3D=3D21225=3D=3D by 0x53EF14: cp_canonicalize_string[abi:cxx11](char co= nst*) (cp-support.c:569)^M =3D=3D21225=3D=3D by 0x561B75: dwarf2_canonicalize_name(char const*, dwa= rf2_cu*, obstack*) [clone .isra.210] (dwarf2read.c:20159)^M =3D=3D21225=3D=3D by 0x566B77: read_partial_die (dwarf2read.c:16264) Can you post your two patches=20 https://github.com/lindsayad/gdb/pull/1/files separately to gdb-patches@sourceware.org? --=20 Yao (=E9=BD=90=E5=B0=A7)