From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: From: Christian Biesinger Date: Mon, 22 Mar 2021 19:09:26 +0100 Message-ID: Subject: Re: GDB memory usage with compressed debug info To: Mike Gulick Cc: Reuben Thomas via Gdb Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-18.3 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 22 Mar 2021 18:10:05 -0000 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