[Bug gdb/28219] New: arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[Bug gdb/28219] New: arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[bmcdonnell at fischerblock dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

            Bug ID: 28219
           Summary: arm-none-eabi-gdb, .../gdb/utils.c:671:
                    "internal-error: virtual memory exhausted: can't
                    allocate 4064 bytes"
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: bmcdonnell at fischerblock dot com
  Target Milestone: ---

Created attachment 13613
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13613&action=edit
gdb crash after breakpoint (VSCode)

Using the latest GNU Arm Embedded Toolchain (10.3-2021.07) available from here:

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

With a Segger J-Link BASE, when I set a breakpoint, the breakpoint hits, but
there is no way for me to control/resume program execution, and the debugger
crashes - as shown in the attached screenshot.

This issue does not occur with GNU Arm Embedded Toolchain 9-2020-q2-update.

Other details of my environment:
 - Windows 10 version 21H1 (OS Build 19043.1110)
 - J-Link tools V7.52c (latest stable)
 - Visual Studio Code (VSCode) 1.59.0 (user setup), with Cortex-Debug plugin
v0.3.13 Preview

----------

GDB error text from screenshot:

/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/src/gdb/gdb/utils.c:671:
internal-error: virtual memory exhausted: can't allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Quit this debugging session?
(y or n) [answered Y; input not from terminal]

This is a bug, please report it.
  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/src/gdb/gdb/utils.c:671:
internal-error: virtual memory exhausted: can't allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Create a core file of GDB?
(y or n) [answered Y; input not from terminal]

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[bmcdonnell at fischerblock dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

bmcdonnell at fischerblock dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bmcdonnell at fischerblock dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[jose.simoes at eclo dot solutions]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

José Simões <jose.simoes at eclo dot solutions> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jose.simoes at eclo dot solutions

--- Comment #1 from José Simões <jose.simoes at eclo dot solutions> ---
I'm having the same problem. Just that I'm using an ST-Link V2 JTAG adapter.
And this occurs whit STM32F769 (Cortex-M7). It doesn't happen with other series
(STM32F4 or L4).

For reference, reported in VS Code here:
https://github.com/microsoft/vscode-cpptools/issues/9219

According to VS Code, this occurs when this call is made:
1: (66101) <-1024-stack-list-frames 0 1000

Any hints on what could be happening? It's with GDB or it's something that VS
Code should be handling differently?

Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[jose.simoes at eclo dot solutions]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #2 from José Simões <jose.simoes at eclo dot solutions> ---
Here's some extra information about this: I'm compiling with -Og and originally
with -ggdb3.

With this I could set the option to stop at `main()` but continuing to the next
line was incredibly slow. Resuming execution works but, on hitting pause
button, the gbd overflow exception would pop and the debug would be terminated.

After changing the build options to -ggdb (or just -g) the debug started to
work again. Stops at main(). Moving to the next line occurs swiftly. Resuming
execution works as expected. And I can now pause and continue execution as many
times as I want.

Tested this with gdb from GCC 8-2019-q3-update and the latest 11.2-2022.02.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[simon.marchi at polymtl dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

Simon Marchi <simon.marchi at polymtl dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon.marchi at polymtl dot ca

--- Comment #3 from Simon Marchi <simon.marchi at polymtl dot ca> ---
The fact it works with -g but not with -g3 hints that it might be the reading
of macro information that is problematic.

Some setups are known to produce wrong / pathological macro information that
cause GDB to be really slow:

https://sourceware.org/bugzilla/show_bug.cgi?id=27754

It would still be surprising that it causes memory exhaustion.

I'd like to help more, but it's a bit difficult, since it's not easily
reproducible without your setup.  If you manage to reproduce with qemu (which
has a GDB stub), it would be really helpful.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

Luis Machado <luis.machado at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luis.machado at arm dot com

--- Comment #4 from Luis Machado <luis.machado at arm dot com> ---
IIRC this was some ld issue and it caused GDB to keep expanding things and
using a lot of memory.

It has been fixed in a later release of the toolchain, 11.3 if I'm not
mistaken.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

Luis Machado <luis.machado at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-10-21
             Status|UNCONFIRMED                 |WAITING

--- Comment #5 from Luis Machado <luis.machado at arm dot com> ---
Could you please give it a try and report back?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[bmcdonnell at fischerblock dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

bmcdonnell at fischerblock dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from bmcdonnell at fischerblock dot com ---
I'm unable to reproduce the issue with Arm GNU Toolchain 12.2.MPACBTI-Rel1. It
appears to have been resolved.

> It has been fixed in a later release of the toolchain, 11.3 if I'm not mistaken.

I did not try the intervening releases to determine in exactly which version it
was fixed.

Note, new toolchain download page:
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[me at dominicclifton dot name]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

Dominic Clifton <me at dominicclifton dot name> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |me at dominicclifton dot name

--- Comment #7 from Dominic Clifton <me at dominicclifton dot name> ---
I would like to add this this is NOT fixed, see GDB traces below:

```
516,275 ~"Reading symbols from
D:\\Users\\Hydra\\Documents\\dev\\projects\\betaflight\\betaflight\\o\
bj\\main\\betaflight_STM32H725_CHONKERH735.elf...\n"
516,333 39-list-thread-groups i1
548,419
~"/data/jenkins/workspace/GNU-toolchain/arm-12-mpacbti/src/binutils-gdb--gdb/gdb/utils.c:717\
: internal-error: virtual memory exhausted: can't allocate 4064 bytes.\nA
problem internal to GDB ha\
s been detected,\nfurther debugging may prove unreliable."
```

12.2.MPACBTI-Rel1

I also confirm that using '-ggdb' vs '-ggdb3' is a working temporary workaround
for me.

When '-ggdb3' is used the GDB sessions takes forever to start and the debugger
will crash.

I also note that I do not experience crashing issues using 9.3.1 of GCC (GNU
Arms Tools release), but every version of GDB since that has the issue.

Here's the list of ones I've tried.

```
 Volume in drive D is NVME1_DATA1
 Volume Serial Number is 0641-FCA8

 Directory of D:\Programs\GNUArmTools

17/07/2023  21:18    <DIR>          .
17/07/2023  21:18    <DIR>          ..
17/07/2023  21:18    <JUNCTION>     active
[D:\Programs\GNUArmTools\gcc-arm-none-eabi-9-2020-q2-update-win32]
27/10/2022  16:58    <DIR>         
arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi
14/03/2023  09:36    <DIR>         
arm-gnu-toolchain-12.2.mpacbti-rel1-mingw-w64-i686-arm-none-eabi
12/12/2022  19:28    <DIR>         
arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi
27/07/2021  10:25    <DIR>          gcc-arm-none-eabi-10.3-2021.07
20/09/2021  11:35    <DIR>          gcc-arm-none-eabi-6-2017-q1-update-win32
20/09/2021  11:35    <DIR>          gcc-arm-none-eabi-6-2017-q2-update-win32
20/09/2021  11:34    <DIR>          gcc-arm-none-eabi-6_2-2016q4-20161216-win32
20/09/2021  11:35    <DIR>          gcc-arm-none-eabi-7-2017-q4-major-win32
20/09/2021  11:36    <DIR>          gcc-arm-none-eabi-7-2018-q2-update-win32
20/09/2021  11:36    <DIR>          gcc-arm-none-eabi-8-2018-q4-major-win32
20/09/2021  11:36    <DIR>          gcc-arm-none-eabi-8-2019-q3-update-win32
20/09/2021  11:37    <DIR>          gcc-arm-none-eabi-9-2019-q4-major-win32
20/09/2021  11:32    <DIR>          gcc-arm-none-eabi-9-2020-q2-update-win32
               6 File(s)            525 bytes
              16 Dir(s)  55,371,231,232 bytes free
```

Please can this be re-opened, triaged and fixed?  Happy to provide more
information as required.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #8 from Luis Machado <luis.machado at arm dot com> ---
Is it possible to reproduce this issue with gdb 13 or top-of-tree gdb? If there
is anything wrong with those, they would be likely candidates to receive a fix.
The gdb shipped with the Arm toolchain is handled by Arm. You could try to
raise it in the community forum (I see someone raised it once here:
https://community.arm.com/support-forums/f/compilers-and-libraries-forum/53983/arm-none-eabi-gdb-out-of-memory)

Can you share an elf file that makes reproducing this easier? I still think
this isn't an issue with gdb itself, but a problem with debug info generation
on some other tool (ld from what I recall). We'd still like to prevent gdb from
crashing though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[me at dominicclifton dot name]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #9 from Dominic Clifton <me at dominicclifton dot name> ---
Hi Luis,

1) I do not have a toolchain or the required pre-requists to build GCC locally
here, however if there are instructions for how to do it somewhere please let
me know and I can try.

2) yes, I will attempt to attach a file to this bug report now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[me at dominicclifton dot name]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #10 from Dominic Clifton <me at dominicclifton dot name> ---
Created attachment 14983
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14983&action=edit
requested .elf file that causes GDB to crash

```
arm-none-eabi-gcc.exe (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build
arm-12-mpacbti.34)) 12.2.1 20230214
```

source for testing:

https://github.com/hydra/betaflight/commits/bf-stm32h725

Note there are two important commits in the branch:

168741486eac3dd0eb43efd40bc20c024ac50904 - changes the Makefile so that '-ggdb'
is used instead of `-ggdb3`
9407467d8be0cab4b492f30d6089f5e1bcd9cadc - parent commit of above used to build
the attached binaries.

Note that if you want to re-build the above binaries from the source you'll
need
```
GCC_REQUIRED_VERSION=12.2.1
```
in `mk\local.mk`, and then build with:

```
make CHONKERH735 DEBUG=INFO EXTRA_FLAGS="-DUSE_TIMER_MAP_PRINT"
```

Full GDB trace log also included in the `.zip` along with the corresponding
`.map` file

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #11 from Luis Machado <luis.machado at arm dot com> ---
Hi Dominic,

Thanks for sharing the data. I gave this a try on Linux, and I can't reproduce
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 DWARF
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 available.

Otherwise, I think using -g as opposed to -g3 might be another workaround for
now, unfortunately.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[me at dominicclifton dot name]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #12 from Dominic Clifton <me at dominicclifton dot name> ---
Hi Luis,

Interesting...

I'm kinda surprised that a binary generated from the .elf with a < 512K
footprint requires over 4GB of RAM to debug.

I have similar crashing issues on other projects I work on, which have a much
smaller codebase, some written in C, others in Rust (not public though).

Yes, I use Windows, and although I use various different shells the GCC arm
bins are always the same ones.

I'm curious as to why 9.3.1 works, which is still 32-bit, without issue,
where-as later versions do not.

What also doesn't make sense to me, yet, is why the crashing behavior isn't
consistent.  Often you can be step-debugging, inspecting registers, viewing
memory, viewing disassembly, etc, all with no issues, and then sometimes when
you single-step it randomly crashes.  When the crash occurs it's always the
same error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #13 from Luis Machado <luis.machado at arm dot com> ---
It is not directly tied to the size of the binary or the size of the debug
information, but older versions of the tools used to produce what was said to
be pathological entries. For instance:

DW_MACRO_import - offset : 0x0

It was investigated a bit more in here:
https://sourceware.org/bugzilla/show_bug.cgi?id=27754

Some hinted at LTO issues, but it doesn't look like it is LTO-specific. Newer
versions of the tools started to behave better, as some users reported. The
fact is that this isn't an issue specific to 32-bit Arm gdb, though the fact
32-bit Arm is widely used/debugged means people may see it more often in that
setup. It is gdb finding some odd input that makes it load more things than it
should. Or load the same data multiple times.

The Windows tools made available by Arm suffer from a couple of issues. First
is the gdb side-effect of bad input. The second is that those Windows tools are
32-bit (which restricts memory use to 4GB). So the first issue may force you to
run into the second one. Not good.

Some suggested we skip the pathological entries in gdb. And there was also a
suggestion to not expand a macro more than once. I did a little experiment with
disabling macro expansion (even in the presence of macro information in the
debug info) and saw a significant memory use drop. It also loads things much
quicker.

I think this might be an opportunity to teach gdb how to deal with these a
little better.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #14 from Luis Machado <luis.machado at arm dot com> ---
Also, I see your elf file contains some of the mentioned pathological macro
import entries. Have you built that elf file with the 12.2-Rel1 release of the
tools? Are you using LTO (it doesn't look like it).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[me at dominicclifton dot name]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #15 from Dominic Clifton <me at dominicclifton dot name> ---
Hi Luis,

thanks again for the continued updates on this.  your replies are much
appreciated.

The code used to build the binary is using LTO, you can see the flags here:

https://github.com/hydra/betaflight/blob/master/Makefile#L153C26-L153C85

specifically: '-flto -fuse-linker-plugin -ffast-math -fmerge-all-constants' are
passed to LD here, via `LD_FLAGS`:

https://github.com/hydra/betaflight/blob/master/Makefile#L288

and to GCC here, via `CC_*_OPTIMIZATION`:

https://github.com/hydra/betaflight/blob/master/Makefile#L429-L453

Yes, the code was built with '12.2-Rel1' too, as mentioned my 'local.mk' has
12.2.1 in it (see https://sourceware.org/bugzilla/show_bug.cgi?id=28219#c10)
and the gcc version is checked before compiling, and I have double checked that
the check is also working. (See
https://github.com/hydra/betaflight/blob/master/mk/tools.mk#L261-L269)

I agree that some improvements should be made in both the generation of debug
information (cc/ld) and in the handling of debug information (gdb).

What's the best way to proceed at this point?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #16 from Luis Machado <luis.machado at arm dot com> ---
Thanks for the additional information. I would've expected the 12.2-Rel1 tools
to contain patches to improve this situation on ld's side.

A see a few ways to improve this situation:

1 - Tools update, which may take a little while. Old tools will still be
broken.
2 - Build the elf without macro information. It may not work if you need to
debug macros.
3 - Teach gdb how to workaround these pathological cases for now (seems
simpler).
4 - Longer term, try to improve memory use for these expansions. It may be a
harder problem to deal with, so it could take some time.

I can raise this issue again on the gdb mailing list for discussion. Meanwhile,
can you do debugging with no macro information?

Simon, do you know if anything has been done with regards to these macro import
issues?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #17 from Luis Machado <luis.machado at arm dot com> ---
Also, I think we might need a new ticket to handle this. It will make things
cleaner. I'll let you know when I open one (or maybe there is one open
already).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[me at dominicclifton dot name]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #18 from Dominic Clifton <me at dominicclifton dot name> ---
Hi again Luis,

> 2 - Build the elf without macro information. It may not work if you need to debug macros.

I have never needed this directly, and I'm not aware if my IDE (Eclipse, CLion,
VSCode) requires this, I doubt it though since I can debug ok using '-ggdb'
which according to the documentation uses the default level of '2' which does
not contain the macro debugging information. 

Using '-ggdb2' instead of '-ggdb3' may be a useful workaround for myself and
others and is a good way to specify that macro debugging information is /not/
used, rather than relying on the default, which may change over time.

Yes, please raise this on the mailing list again, with a priority given to
option 3, making GDB workaround the issue, which is a solution that will not
have to wait for a tools update and should provide immediate benefits.

Yes, please add me to the CC list or ping me for the new issue when you create
it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[simon.marchi at polymtl dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #19 from Simon Marchi <simon.marchi at polymtl dot ca> ---
> Simon, do you know if anything has been done with regards to these macro
> import issues?

As far as I know, the issue is still present.  It would be nice to make GDB
detect the situation and avoid getting in the combinatorial explosion, but care
must be taken to not reject valid cases.  For instance, I don't think that
simply skipping all "import 0" would work, as you could have legitimate (not
far-fetched) use cases of that.

However, I checked the .elf file uploaded recently by Dominic, and I don't see
any "import 0" in the .debug_macro section.  Are we sure we are looking at the
same issue?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #20 from Luis Machado <luis.machado at arm dot com> ---
Interesting. I grepped for it and saw 981 cases of this:

DW_MACRO_import - offset : 0x0

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[simon.marchi at polymtl dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #21 from Simon Marchi <simon.marchi at polymtl dot ca> ---
(In reply to Luis Machado from comment #20)
> Interesting. I grepped for it and saw 981 cases of this:
> 
> DW_MACRO_import - offset : 0x0

My bad, I did not check carefully.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28219] arm-none-eabi-gdb, .../gdb/utils.c:671: "internal-error: virtual memory exhausted: can't allocate 4064 bytes"

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28219

--- Comment #22 from Luis Machado <luis.machado at arm dot com> ---
No worries. Thanks for confirming.

So it does look like this particular elf file is affected by those odd debug
info entries. I'll have to investigate it a bit to remember what the context
was behind these slowdowns.

-- 
You are receiving this mail because:
You are on the CC list for the bug.