Created attachment 5778 [details] elf file I used When I use GDB to debug arm program, it failed to load elf file compiled by ARM RVCT. It can load elf compiled by ADS1.2. But RVCT3.1 and ADS1.2 are using the same dwarf version (dwarf 2) the error message as below: ../../gdb-7.1.50.20100521/gdb/utils.c:1269: internal-error: virtual memory exhausted: can't allocate 21390954 bytes. Attached please find the elf file. thank you very much to help me!
Created attachment 5779 [details] error screen
> > the error message as below: > ../../gdb-7.1.50.20100521/gdb/utils.c:1269: internal-error: virtual memory > exhausted: can't allocate 21390954 bytes. Your GDB is quite old. Can gdb cvs trunk or 7.2 have the same problem?
(In reply to comment #2) > > > > the error message as below: > > ../../gdb-7.1.50.20100521/gdb/utils.c:1269: internal-error: virtual memory > > exhausted: can't allocate 21390954 bytes. > Your GDB is quite old. Can gdb cvs trunk or 7.2 have the same problem? thank you very much! I tried gdb 7.2 again. the same problem, only different line number. ../../gdb-7.2/gdb/utils.c:1401: internal-error: virtual memory exhausted: can't allocate 213909504 bytes. I thought there may be some memory leak when gdb loading elf compiled by rvct3.1 I searched this kind of usage, gdb + rvct3.1, but there is no result. So I think there maybe nobody used it.
Additional information: Environment: C, C++, RVCT 3.1 (1021), dwarf2, Host=i686-pc-mingw32, target=i686-pc-mingw32 When I changed to use RVCT 3.1 (569) to link the elf, it can be loaded successful. Then, I changed to another big project and used RVCT 3.1 (569) to link, it fails to be loaded this time. So file size is one of the affect factor. I'm trying to change the target (target=i686-pc-mingw32 -> target=arm-elf)...
Status update: We found that it is always ok when using elf compiled by RVCT3.1(Build 1021), even big file size
The DWARF in this file is corrupt and causes a loop in the structure of the debug information, causing gdb to allocate increasing amounts of memory. It's not clear that it can be avoided with this type of corruption.
(In reply to Will Newton from comment #6) > The DWARF in this file is corrupt and causes a loop in the structure of the > debug information, causing gdb to allocate increasing amounts of memory. > It's not clear that it can be avoided with this type of corruption. Could you post your analysis and say what exactly is wrong with the DWARF? I think it is valuable to try to harden gdb against this kind of error.
via b9502d3fd7848cd4d843be8bdc28633a3d24438d (commit) from 452a569eff947a21369d43cc7632c320e5b8a085 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b9502d3fd7848cd4d843be8bdc28633a3d24438d commit b9502d3fd7848cd4d843be8bdc28633a3d24438d Author: Will Newton <will.newton@linaro.org> Date: Fri Nov 1 14:14:50 2013 -0700 gdb/dwarf2read.c: Sanity check DW_AT_sibling values. When reading objects with corrupt debug information it is possible that the sibling chain can form a loop, which leads to an infinite loop and memory exhaustion. Avoid this situation by disregarding and DW_AT_sibling values that point to a lower address than the current entry. gdb/ChangeLog: 2013-11-06 Will Newton <will.newton@linaro.org> PR gdb/12866 * dwarf2read.c (skip_one_die): Sanity check DW_AT_sibling values. (read_partial_die): Likewise. ----------------------------------------------------------------------- Summary of changes: gdb/ChangeLog | 6 ++++++ gdb/dwarf2read.c | 22 ++++++++++++++++++++-- 2 files changed, 26 insertions(+), 2 deletions(-)
The commit b9502d3fd7848cd4d843be8bdc28633a3d24438d fixes this issue.