From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id DQMyARmaW2BsagAAWB0awg (envelope-from ) for ; Wed, 24 Mar 2021 15:59:21 -0400 Received: by simark.ca (Postfix, from userid 112) id E7AA21EF7C; Wed, 24 Mar 2021 15:59:20 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 387851EF5D for ; Wed, 24 Mar 2021 15:59:20 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CDF9C3851C24; Wed, 24 Mar 2021 19:59:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CDF9C3851C24 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1616615959; bh=lV/ZbAl7DM9vn599BKBy3D2E/Dd72AuYlljZv63pJ1g=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=HlpOTwFZyblwspOLE1kIefCoL05NDo6GWEeDg2H0L+1TM9IYfcAEvO2oXnqmt64kw GBBhQTyFWTfehoOoo9OIvGxNvSbvgejWIqH0hw/Br4HF7ENAPTgsS/67To08ZlBwyH fF1xDqfmY/5ePvbDj71sQ4ijlTkCdn04+PlgRxAw= Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id ECA3C3851C24 for ; Wed, 24 Mar 2021 19:59:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ECA3C3851C24 Received: by mail-wm1-x32c.google.com with SMTP id r10-20020a05600c35cab029010c946c95easo1876929wmq.4 for ; Wed, 24 Mar 2021 12:59:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ms2kJUWYltQ0zhqYgtTTtYWqjIW7ndJzJSgp+GHLo+o=; b=qMXTVat37kNZe5YVY4ARy5fTLSh3jBy2PrAX466kT4Ixfra5LMuHGKOErR0MUISZ0i DojcRXhjXHVTWC/dJfHutL6MRATL0y6pGRwxs4eKGcWsukn8RQpJPyI3Yjhkq+6KFKWZ aQstspSaT0mMaZO7i68m3FzVcFKT5vHVLWGCoTb5vq4Tn0r5838n7WeW2uhtgtw5yomF Z6vn+ReZUsg+NhHbm5zbZvpykMrafslpUShOTEAMSYmXa9TpV3w9ZiYRBqQL6NfwK08S 9vdYGfFphKiH1YwtEvfKhX+yDPFUjLy4KXZ/F8cUbjkgjyh3UHLzKwMNkAH8umLzafdh FVug== X-Gm-Message-State: AOAM5337Txlpb3MVS8wJo6eDimGeCnqDR9lPiOG4Eti3jfgwwiVRvJd0 Z3NxF8VgqH5nFcK86JOouClavja0TY4MuI/iplM= X-Google-Smtp-Source: ABdhPJzX3pY4NmKXlYO+9a6Gb6C72xvCjvzoWaPAWR5ZK2lsRRz5iq9jjSFp+/0KjDeVcxgd/c6P4fy9O6njoS0Y668= X-Received: by 2002:a1c:5f54:: with SMTP id t81mr4547444wmb.84.1616615956121; Wed, 24 Mar 2021 12:59:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 24 Mar 2021 19:59:04 +0000 Message-ID: Subject: Re: GDB memory usage with compressed debug info To: Christian Biesinger Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Matt Rice via Gdb Reply-To: Matt Rice Cc: Reuben Thomas via Gdb , Mike Gulick Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" On Mon, Mar 22, 2021 at 6:16 PM Christian Biesinger via Gdb < gdb@sourceware.org> wrote: > On Thu, Mar 18, 2021 at 7:38 PM Mike Gulick via Gdb > wrote: > > > > On 3/16/21 2:40 PM, Mike Gulick wrote: > > > Hi, > > > > > > I'm observing that GDB memory usage is much higher when I have debug > > > info compressed with 'objcopy --compress-debug-sections'. In a large > > > C++ application, I see the instance with uncompressed debug info use > > > 46GB VIRTUAL memory and 11GB RSS, and the instance with compressed > debug > > > info is using 46GB VIRTUAL memory and 42GB RSS. In case it matters, > the > > > debug info is separated from the original binary into its own file. > > > > > > It seems like GDB must load the full uncompressed debug info into > memory > > > when the underlying files are compressed? > > > > > > I'm currently using GDB 9.2. I checked the 10.1 NEWS and didn't see > > > anything that looked like it would have changed this result, but I'm > > > happy to give it a try if you think it might help. > > > > > > Is there any chance this could be improved with a patch to GDB, or is > > > this just the nature of compressed debug data? > > > > > > Also, FYI, the NEWS link for the GDB 10.1 release on the GDB home page > > > points to the NEWS file for the 9.1 release. > > > > > > Thanks! > > > > > > -Mike > > > > I should add that this high memory usage only occurs when there is a > > FILE:LINENUM breakpoint set (or pending). I can run the application > > being debugged, observe that GDB's memory usage is around 11 or 12 GB, > > then run 'b foobar.cpp:123', and the GDB memory usage will climb up to > > 42 GB. Interesting that symbolic breakpoints don't trigger this high > > memory usage, but line-based breakpoints do. Does this seem expected? > > I'm guessing that this is due to parsing full debug info ("expanding > psymtabs") which is not necessary for symbolic breakpoints, which can > rely on minsyms or maybe psymtabs. Have you tried using a heap > profiler to see where the memory usage comes from? > It could possibly narrow it down if the behavior of FILE:label breakpoints differ, though I'm not sure what to expect exactly.