Arm Community
Site
Search
User
Site
Search
User
Groups
Education Hub
Distinguished Ambassadors
Open Source Software and Platforms
Research Collaboration and Enablement
Forums
AI and ML forum
Architectures and Processors forum
Arm Development Platforms forum
Arm Development Studio forum
Arm Virtual Hardware forum
Automotive forum
Compilers and Libraries forum
Graphics, Gaming, and VR forum
High Performance Computing (HPC) forum
Infrastructure Solutions forum
Internet of Things (IoT) forum
Keil forum
Morello forum
Operating Systems forum
SoC Design and Simulation forum
SystemReady Forum
Blogs
AI and ML blog
Announcements
Architectures and Processors blog
Automotive blog
Graphics, Gaming, and VR blog
High Performance Computing (HPC) blog
Infrastructure Solutions blog
Internet of Things (IoT) blog
Operating Systems blog
SoC Design and Simulation blog
Tools, Software and IDEs blog
Support
Arm Support Services
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Support forums
Compilers and Libraries forum
arm-none-eabi-gdb out of memory
Jump...
Cancel
State
Not Answered
Locked
Locked
Replies
0 replies
Subscribers
19 subscribers
Views
1334 views
Users
0 members are here
GNU Toolchain
Options
Share
More actions
Cancel
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion
arm-none-eabi-gdb out of memory
tschulz
over 1 year ago
I'm developing on a embedded application running on an STM32F405 processor. I'm using VSCode and arm-none-eabi-gcc/gdb on Windows (10).
As my application grew I experienced that debugging became increasingly slower and unstable. I could step through some code, but eventually this became almost unusable.
I have now resorted to just using the debugger with the command line, windows command prompt.
Sometimes I get a terminal output like this:
/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/src/gdb/gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 4064 bytes.
A problem internal to GDB has been detected,
Other times arm-none-eabi-gdb.exe seems to just get killed, probably because it hits the 2GB memory limit for a 32bit process.
Stepping through simple instructions seems to work without problem. But when a function from a new source file is being called (a function from a source file that hasn't been used in the current session yet), memory consumption increases excessively. And memory is never been deallocated.
Here is the way I run an actual debug session:
Terminal 1:
pyocd gdb --target STM32F405VG -O reset_type=hw -O connect_mode=under-reset
Terminal 2:
arm-none-eabi-gdb.exe board.elf
target remote localhost:3333
monitor reset halt
break main
cont
# At first breakpoint
next
next
... and so on.
When stepping though the code, observe the memory consumption of arm-none-eabi.gdb.exe. The Windows task manager - Details view will do.
Memory consumption doesn't change much when executing functions that reside in the same source file, but when a function from a new file is being called, there will be a significant increase in memory consumption of the gdb processs - until it fails.
I've tried a number of versions of arm-none-eabi-gdb.exe, all behave similar:
10 2020-q4-major
10 2021.10
9 2020-q2-update
and
Arm GNU Toolchain 12.2.MPACBTI-Bet1 (Build arm-12-mpacbti.16)) 13.0.50.20220406-git
It turns out I get to crash the debugger even without having a debug session to the target board:
Terminal Session, no pyocd needed:
arm-none-eabi-gdb.exe -nx board.elf
list main # code in main.cpp
list function1 # code in file1.cpp
list function2 # code in file2.cpp
.. and so on. In my system, gdb reaches the 2GB limit after about 8 of these list calls.
Even a commad like "info locals" runs to occupy a very sizeable amount of memory.
The application image that I'm running is about 230KB big at present. Sometimes it looks like the memory consumption of arm-none-eabi-gdb increases by about that amount.
It is a logging application that is being ported to MBed OS. In general, the application works, It is not running out of memory on its own.
Anyone has seen something similar, like arm-none-eabi-gdb.exe running out of memory?