This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/16371] New: "info stack" causes virtual memory exhaustion
- From: "freddie_chopin at op dot pl" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 26 Dec 2013 23:02:06 +0000
- Subject: [Bug gdb/16371] New: "info stack" causes virtual memory exhaustion
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16371
Bug ID: 16371
Summary: "info stack" causes virtual memory exhaustion
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: freddie_chopin at op dot pl
I have a program for bare-metal ARM microcontroller, that behaves a bit strange
with the most recent GCC and GDB. I start a gdb session and do the minimum:
- target remote localhost:3333
- monitor reset init
- tbreak main
- c
- c
- [Ctrl+C to halt]
- info stack
At this point GDB starts to eat all available memory, when it hits almost 2 GB
it is terminated by OS. The prompt at this point:
---
(gdb) info stack
#0 prvIdleTask (pvParameters=0x0) at FreeRTOS/tasks.c:2150
#1 0x08001e04 in ulPortSetInterruptMask ()
at FreeRTOS/portable/GCC/ARM_CM3/port.c:395
Recursive internal problem.
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
---
If I do the debugging in Eclipse then I'm sometimes able to see also this in
another prompt:
---
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
/home/freddie/bleeding-edge-toolchain/src/gdb/gdb/utils.c:1072: internal-error:
virtual memory exhausted: can't allocate 88 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
---
(the numbers - 88 - are the same every time)
If I use some older version of GDB (versions I compiled in May and version
compiled by someone else, repository date - end of June) work fine:
---
(gdb) info stack
#0 prvIdleTask (pvParameters=0x0) at FreeRTOS/tasks.c:2150
#1 0x08001e04 in ulPortSetInterruptMask ()
at FreeRTOS/portable/GCC/ARM_CM3/port.c:395
#2 0x08001e04 in ulPortSetInterruptMask ()
at FreeRTOS/portable/GCC/ARM_CM3/port.c:395
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
---
Now here are the funny things.
1. The problem occurs only if I do "info stack" in some FreeRTOS task. If I
happen to do that in a interrupt everything is fine. If I do that before the
RTOS is started (in main() or some of functions called from there) - everything
is fine.
2. If I compile my program with an older compiler (GCC 4.7 instead of GCC 4.8)
it also works fine... The program itself works fine no matter what compiler I
use. This point is probably important, so I'll try to elaborate some more
- gcc 4.8 + GDB from 10.08.2013 or after - fails
- gcc 4.8 + GDB from 31.07.2013 of before - works
- gcc 4.7 + any GDB - works
3. Somehow the problem happens only in this single project, other programs seem
to work fine - no matter what...
I can try to provide more info, but it's hard to provide a complete test case,
as "small" tests work, other programs too, just this one misbehaves and it's
pretty big...
Thx in advance!
BTW - I compiled GDB from git://sourceware.org/git/gdb.git - I guess I should
have used the new binutils-gdb repo, but I hope that it's not the reason of my
problems.
--
You are receiving this mail because:
You are on the CC list for the bug.