From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20212 invoked by alias); 4 Aug 2017 21:43:28 -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 18908 invoked by uid 89); 4 Aug 2017 21:43:27 -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=viewable, decrease X-HELO: mail-it0-f49.google.com Received: from mail-it0-f49.google.com (HELO mail-it0-f49.google.com) (209.85.214.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 Aug 2017 21:43:25 +0000 Received: by mail-it0-f49.google.com with SMTP id v127so14157778itd.0 for ; Fri, 04 Aug 2017 14:43:25 -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:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YZM2jt7yXrKlTiffPyPpSLVWmzbVFt1keMORKWbC5io=; b=dHCQGm9BkGsDtUS4PAlO4RQN/K300+912x0BPVIrRp3896qvytpYM9PDZnuTbk+Abq B44dXPmYTZS3RvajFojTbkbbFVIm6b3yvPapl5FbtghS1QHrJtxssyimyv/WiBAwyREh LlmPcMRSeQnhPPs0mWVDVMBug87Q3kG122rhGW/W3QkPfjndDngI0J+bRgnkOze8fRop D8jCxcROnKyF7m0GGik9CSkMiQbVzkEi9zW3iWT3flsB9eH5P7vK9GVez1S6L2I54TnW iJCvSgkBJsS0JHDMv8jZGh549MxN0uoV2XtlwPPX+JQgpRlNPL1y2SPjButWsz7OswWU gOeA== X-Gm-Message-State: AIVw111y0QJA9x8/qyKzucFJFWuF0iNvujXXdr8dTf/sh1kWSOsRc1o1 Zh2mpxXkLf8k1zHlbGw= X-Received: by 10.36.118.194 with SMTP id z185mr3830773itb.66.1501883004075; Fri, 04 Aug 2017 14:43:24 -0700 (PDT) Received: from [128.174.163.204] ([128.174.163.204]) by smtp.gmail.com with ESMTPSA id t5sm1158765ita.22.2017.08.04.14.43.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 14:43:23 -0700 (PDT) From: Alex Lindsay Subject: Re: Large memory usage by gdb To: gdb@sourceware.org References: <420b109c-1610-d687-ae9a-b172542fafca@gmail.com> Message-ID: <6f204cea-21bf-3f70-aa61-df02aeba8a24@gmail.com> Date: Fri, 04 Aug 2017 21:43: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: <420b109c-1610-d687-ae9a-b172542fafca@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00010.txt.bz2 So I wanted to share what I've been doing to make sure that I'm not wasting my time (or the list's). Since this is my first deep dive into valgrind, I started "simple". I've been running more or less: valgrind --xtree-leak=yes gdb --args ./hello Where `hello` is just a hello world program. My initial leak report was: ==5923== LEAK SUMMARY: ==5923== definitely lost: 734,882 bytes in 6,231 blocks ==5923== indirectly lost: 42,581 bytes in 6 blocks ==5923== possibly lost: 112,422 bytes in 327 blocks ==5923== still reachable: 8,514,469 bytes in 16,790 blocks ==5923== suppressed: 0 bytes in 0 blocks with the initial call-graph (call-graphs viewable at https://github.com/lindsayad/markdown-notebooks/blob/master/gdb/images-for-list.md). Consequently, I made some changes in the `cp_canonicalize_string` function of `cp-support.c` (viewable at https://github.com/lindsayad/gdb/pull/1/files). Subsequent running of the same valgrind command resulted in the new summary: ==1748== LEAK SUMMARY: ==1748== definitely lost: 74,226 bytes in 21 blocks ==1748== indirectly lost: 42,581 bytes in 6 blocks ==1748== possibly lost: 111,142 bytes in 324 blocks ==1748== still reachable: 8,515,463 bytes in 16,791 blocks ==1748== suppressed: 0 bytes in 0 blocks and a new call-graph. I was fairly pleased that I reduced the number of definitely lost bytes by an order of magnitude. So iterating again, I made some changes to `elfread.c` and generated the new summary: ==30129== LEAK SUMMARY: ==30129== definitely lost: 37,538 bytes in 15 blocks ==30129== indirectly lost: 0 bytes in 0 blocks ==30129== possibly lost: 111,142 bytes in 324 blocks ==30129== still reachable: 8,512,473 bytes in 16,788 blocks ==30129== suppressed: 0 bytes in 0 blocks and new call-graph. So my question is, is what I'm doing valuable? I 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). Thanks for your time, Alex On 08/01/2017 02:11 PM, Philippe Waroquiers wrote: > On Mon, 2017-07-31 at 17:11 -0500, Alex Lindsay wrote: >> Philippe, >> >> Is memcheck a better tool to use here compared to massif? > In valgrind 3.13, memcheck provides a quite detailed/precise > way to see delta memory increase/decrease. > Typically, you will give --xtree-memory=full argument, > and then e.g. use vgdb to launch a (delta) leak search > after each run. > You can then use kcachegrind to visualise the resulting > memory increase. > > Massif is IMO less precise, but automatically produces > memory status at regular interval. > > So, in summary, I would use valgrind 3.13 and memcheck > (with an additional benefit that if ever your use case > causes real memory leaks, memcheck will detect them). > > Philippe > >> Alex >> >> On 07/25/2017 03:28 PM, Philippe Waroquiers wrote: >>> Run gdb under Valgrind, and make some heap profiling dump at regular >>> interval, (e.g. after each run). >>> >>> With valgrind 3.12 or before, you can do a leak report to show >>> the delta (increase or decrease) compared to the previous leak search, >>> including the reachable blocks. So, you will be able to see what >>> increases the memory. >>> >>> If you compile the latest Valgrind (3.13), you can e.g. use memcheck >>> and produce heap profiling reports readable with kcachegrind. >>> >>> You will need a gdb compiled with debug or install the debug info >>> of gdb to have understandable stack traces. >>> >>> Philippe >>> >>> On Tue, 2017-07-25 at 15:20 -0500, Alex Lindsay wrote: >>>> My OS is Ubuntu 17.04. Using both gdb 7.12 and 8.0, I experience large >>>> memory usage when debugging my executable. As I add breakpoints and run >>>> the executable multiple times in a single session, memory usage grows >>>> continuously, regularly hitting 10s of GBs. I don't recall experiencing >>>> this issue with earlier Ubuntu versions (and also likely earlier >>>> versions of gdb). When I debug the same executable with `lldb`, memory >>>> usage is pretty much constant at around 2 GB. Does anyone have any >>>> suggestions? >>>> >>>> Alex