From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125610 invoked by alias); 25 Jul 2017 20:28:59 -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 125071 invoked by uid 89); 25 Jul 2017 20:28:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_05,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*F:D*be, hitting, continuously, 10s X-HELO: mailsec105.isp.belgacom.be Received: from mailsec105.isp.belgacom.be (HELO mailsec105.isp.belgacom.be) (195.238.20.101) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 25 Jul 2017 20:28:55 +0000 IronPort-PHdr: =?us-ascii?q?9a23=3AMBkkxB+H3X4NBf9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?0+IcTK2v8tzYMVDF4r011RmSDNWds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?us-ascii?q?8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1?= =?us-ascii?q?Ifn+FpLPg8it2e2//57ebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+?= =?us-ascii?q?RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTF?= =?us-ascii?q?UACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMNboRr4oRzut86ZrSAfpiC?= =?us-ascii?q?gZMT457HrXgdF0gK5CvR6tuwBzz4vSbYqINvRxY7ndcMsZS2RcXshfSSJPDYGy?= =?us-ascii?q?b4QTCOQOMulWopLhp1YMtxayGROhCP/txzJOm3T43bc60+MkEQzexgIgH9MOsH?= =?us-ascii?q?DVrNXtLKcdT/2+w6nSwjXZaPNWwCr96InWfRA7uvGHQLV9cdLRyUkuEwPFj02Q?= =?us-ascii?q?qZT7MD+P2OUCqXKb7+15VeKyim4otRtxoiO0y8c3iYnIhoQVxU7Y9Slj24k6O8?= =?us-ascii?q?S1RUhmatCnCJtdryKXOolsTs4jQ2xkojs2xqEJtJKhciUHyZIqzAPFZfOdaYiH?= =?us-ascii?q?+BfjWf6UITd/mX1qZqqyhw238Ui80u38UdS00EpSoipFjNbMsncN2gTW6seaUv?= =?us-ascii?q?d9/0Gh1iiT1w3L6exJI1o4mKvbJpI737I8ipUevV7NEyL3gEn2ibWZdkQg+uim?= =?us-ascii?q?8eTnZbDmq4eEN490iwH+NqUumtSnAesmKAQPUXKU+f671L364E35QatFjuctkq?= =?us-ascii?q?TCq5DaJsQapqinDA9JyIos8AiwAy+80NsEhXkHME5FeBWfgofzP1HBPv/5DfO+?= =?us-ascii?q?g1SqjThr3OrJP73/DpjDKnXOi7jhfbNn5E5dzAo/18xQ55VRCuJJHPWmc0v8pJ?= =?us-ascii?q?T8Dxk1KAWli7LuDNht0oIYVXmGE/XCYYvdtFaJ4qQkJOzaN6EPvzOoE/gk4//2?= =?us-ascii?q?lXJxplYHerC03JYNczjsBvRnJ0SBeXeqnd4bFn4XvwckV8Txi0yEXCIVbXvkDP?= =?us-ascii?q?F03S0yFI/zVdSLfYuqmrHUmX7jRpA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CyAgABqXdZ/yRoQVddGwEBAQMBAQEJA?= =?us-ascii?q?QEBFgEBAQMBAQEJAQEBgy9EhFyLV5B1LAGVWYIShUcCgzdBFwEBAQEBAQEBAQE?= =?us-ascii?q?BaiiCMyQBgkEBBSMzIxAIAxgCAiYCAjkeBopGsRSCJotKAQEIAiaBC4Idg02FB?= =?us-ascii?q?YgGgmEFn1eCKJF3kjmVaSEBNYEKdId8PolrAQEB?= X-IPAS-Result: =?us-ascii?q?A2CyAgABqXdZ/yRoQVddGwEBAQMBAQEJAQEBFgEBAQMBAQE?= =?us-ascii?q?JAQEBgy9EhFyLV5B1LAGVWYIShUcCgzdBFwEBAQEBAQEBAQEBaiiCMyQBgkEBB?= =?us-ascii?q?SMzIxAIAxgCAiYCAjkeBopGsRSCJotKAQEIAiaBC4Idg02FBYgGgmEFn1eCKJF?= =?us-ascii?q?3kjmVaSEBNYEKdId8PolrAQEB?= Received: from 36.104-65-87.adsl-dyn.isp.belgacom.be (HELO md) ([87.65.104.36]) by relay.skynet.be with ESMTP/TLS/AES128-GCM-SHA256; 25 Jul 2017 22:28:52 +0200 Message-ID: <1501014538.2145.22.camel@skynet.be> Subject: Re: Large memory usage by gdb From: Philippe Waroquiers To: Alex Lindsay Cc: gdb@sourceware.org Date: Tue, 25 Jul 2017 20:28:00 -0000 In-Reply-To: <8d511930-9914-9aef-363f-2fff37dfc6a8@gmail.com> References: <8d511930-9914-9aef-363f-2fff37dfc6a8@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00040.txt.bz2 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