This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/16371] New: "info stack" causes virtual memory exhaustion


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]