Arm Community
Site
Search
User
Site
Search
User
Groups
Research Collaboration and Enablement
DesignStart
Education Hub
Innovation
Open Source Software and Platforms
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
中文社区论区
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
Innovation blog
Internet of Things (IoT) blog
Operating Systems blog
Research Articles
SoC Design and Simulation blog
Smart Homes
Tools, Software and IDEs blog
Works on Arm 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
New
State
Not Answered
Replies
0 replies
Subscribers
15 subscribers
Views
141 views
Users
0 members are here
GNU Toolchain
Options
Share
More actions
Cancel
Related
How was your experience today?
arm-none-eabi-gdb out of memory
Offline
tschulz
1 month 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?