From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JwhLBIHdWGA1JAAAWB0awg (envelope-from ) for ; Mon, 22 Mar 2021 14:10:09 -0400 Received: by simark.ca (Postfix, from userid 112) id F2A5E1EF78; Mon, 22 Mar 2021 14:10:08 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 3F3F11E54D for ; Mon, 22 Mar 2021 14:10:07 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B717E3858D29; Mon, 22 Mar 2021 18:10:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B717E3858D29 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1616436606; bh=JcVJjO/uAfeV9aw6Ju5obS7cq4BqyrHBuR66wzGjKEc=; 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=PPiuYR7I2qmA7lpquYCzWVlvoGV7vIPYBzE1sivgP6Ux3rQJjOgwuDxJLJg2Idlpi 00TrikKuHKgx1S3xNeCmpEvVlhGY+FtIGN9GOm5XqPJi5t/japSpJeBngADp/iuC7f 3CJouLeeCyPC8wt02lswMNIpBotfTATuIfKeUVuM= Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 13EA6385483E for ; Mon, 22 Mar 2021 18:10:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 13EA6385483E Received: by mail-wr1-x42f.google.com with SMTP id z2so18152173wrl.5 for ; Mon, 22 Mar 2021 11:10:04 -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=JcVJjO/uAfeV9aw6Ju5obS7cq4BqyrHBuR66wzGjKEc=; b=PPd+q6tF08iUkC0cI0TLX25Ta990nCKS9JQA5+09FF3r/QpEuwnorMQCH/xBqAvv61 xTEzZaD8gxiMNqILVCqioSrjnUvlRJebqAxUVhxr1LjBkKPpshkVk0sPUK4fvoPhf2pg tnhee1dbRwGFJqCPBQeDCJbZtXIqq+wgzmv9CmZ3KXn/1PhiMYgSJSx6QfLMLS26UeV/ 1BebVCTxRmm7KQALsvVYkrMYLJnj33Bu7FjnK46VCJuyQEEhrfX6YrWdEov1AkhWo1GK eKzojmqGg4O3w23d2FiVtQdJz7nAaARJZciy/SoMIiDtxAGAX3oV5K8PERkorCXXNfRa dEHA== X-Gm-Message-State: AOAM531RomCcYHS/7onSwSsGns2xzUiAbsHf3dQ+Pgao3xLCyM3rR2gh oSGU+CZdLl5qAGfx7SGMTJMbD6ADFRGmFHct/CDjwQ== X-Google-Smtp-Source: ABdhPJxj/yttYH3b+z0fXSsWpGp11BJTOxpJd+qwtviLtPwPwUDUX4DXtU2hbF2HiFGuhZ43SNPI+pihICz59dPikl0= X-Received: by 2002:adf:f60b:: with SMTP id t11mr771862wrp.269.1616436603056; Mon, 22 Mar 2021 11:10:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 22 Mar 2021 19:09:26 +0100 Message-ID: Subject: Re: GDB memory usage with compressed debug info To: Mike Gulick Content-Type: text/plain; charset="UTF-8" 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: Christian Biesinger via Gdb Reply-To: Christian Biesinger Cc: Reuben Thomas via Gdb Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" 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? Christian