From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 413B03858C2D for ; Mon, 14 Nov 2022 14:47:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 413B03858C2D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B82FC1E0D3; Mon, 14 Nov 2022 09:47:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1668437259; bh=fL5x6FGMoX6K5rx8oQQzVn+8XIWsDcxaYQNrHIFy/tc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=sGB+tUe7pqUvzIlmkm9R7imtPzPopUz4N6XOSdTFx3e8P3b9CR0xcrER3CRjU3Rjc KqqUhiS91KskxRVhhgG+vDK59CqIVECi2KnbFyoATdIhvSWSUu9RqKyLLh1z+3OvpG /21p8Q2pV3R3pmJZz8idEq1X7wzNuYEDk8o47nlg= Message-ID: <5a0a91a5-fc65-c9e9-89ea-035884b9c867@simark.ca> Date: Mon, 14 Nov 2022 09:47:38 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: memory increased rapidly when adding a break Content-Language: en-US To: DeJiang Zhu Cc: gdb@sourceware.org References: From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Thanks for your detailed explanation. > Yes, it's `utility.h:560`, I added this break from vscode. > >> creating some internal data structures to represent it > > I wonder where would allocate so much memory, (at least 40GB), > while the binary is 985MB with the whole debug info. > Maybe many match results need too many memories? It's hard to tell if it's a GDB bug, or it's working as expected, just that GDB is inefficient. If you end up expanding all CUs, it's not unrealistic. I've just ran gdb on itself, and did "maint expand symtabs" to force the expansion of all symtabs. htop shows 4.6 GB of virtual memory used. So I can imagine that for a project 10 times bigger, it can take 10 times more memory. >> >> Although I'm not sure this is what you see. >> >> Is the project you build something open source that other people could >> build and try? >> > > Yes, it's an open source project. > It builds with Bazel and depends on Go, which may be a bit complicated. > This is the doc for build & run. > https://github.com/mosn/envoy-go-extension#envoy I'm curious, so I built that, but then I'm not sure what to do, how to reproduce your case. Simon