From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 734EE3858C33; Wed, 19 Jul 2023 09:56:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 734EE3858C33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1689760580; bh=75wE0c2OvM7VlVEDcVO6+23+AVQDeXUcTmbvCg90yEQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=p0sOeyWC2IcZrayR2pjKkUR9jOVkfdGGcFwVdalu+DKrpm9mYE2ROyfBD+zTKjXHG tbSGbRQzjjh3RzZeiQs4ZidEXajTcr6z6cyv+vLqJ1814xXadfUOftWeSWkyFhGJCU dcxbE1hYQO8YEZ05UN2pW+4+aJNvmxxca5X4V7Vk= From: "luis.machado at arm dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes" Date: Wed, 19 Jul 2023 09:56:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: luis.machado at arm dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D28219 --- Comment #11 from Luis Machado --- Hi Dominic, Thanks for sharing the data. I gave this a try on Linux, and I can't reprod= uce it with any of master, 12.1-Rel1 or 11.3-Rel1 gdb's. I did notice newer gdb= 's take longer to load data, and that is most likely due to a rewrite in the D= WARF reader that cause some slowdowns in some situations. Now, I've noticed you are using the windows version of the Arm toolchain. In that case, the gdb binary will be a 32-bit executable. During reading of symbols and debug info, expansions (specially with macro info) may cause gdb to go over the limit of 4GB. While that is not an issue= for a 64-bit process, it likely is for a 32-bit process. I think that is a limitation of the Windows toolchain release at the moment (shipping 32-bit binaries). I'd advise getting in touch through the Arm community forum and checking when 64-bit tools for Windows will be availabl= e. Otherwise, I think using -g as opposed to -g3 might be another workaround f= or now, unfortunately. --=20 You are receiving this mail because: You are on the CC list for the bug.=