From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3696 invoked by alias); 14 Aug 2003 11:03:36 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3687 invoked from network); 14 Aug 2003 11:03:36 -0000 Received: from unknown (HELO maxipes.logix.cz) (81.0.234.97) by sources.redhat.com with SMTP; 14 Aug 2003 11:03:36 -0000 Received: from suse.cz (styx.suse.cz [213.210.157.162]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "Michal Ludvig", Issuer "Personal Freemail RSA 2000.8.30" (verified OK)) by maxipes.logix.cz (Postfix) with ESMTP id C2893299D6; Thu, 14 Aug 2003 13:03:34 +0200 (CEST) Message-ID: <3F3B6C99.6020908@suse.cz> Date: Thu, 14 Aug 2003 11:03:00 -0000 From: Michal Ludvig Organization: SuSE CR, s.r.o. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.5b) Gecko/20030813 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: gdb Cc: Daniel Jacobowitz , Elena Zannoni Subject: Re: Dwarf2-related Internal error References: <3F0AD6F4.9060709@suse.cz> In-Reply-To: <3F0AD6F4.9060709@suse.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00145.txt.bz2 Hi Daniel, Elena and others, this problem is still present in recent HEAD - could anyone who knows the internals of symbols handling and .debug_info please help me with fixing it, please? I tried to debug it myself but got quickly lost in all those symbols<->types<->other_types references and couldn't find where the problem originates. Also pointing out the right direction where to look for the bug would help me a lot :-) BTW I also filled a PR with a very nice number 1333 for this issue. Thanks in advance! Michal Ludvig Michal Ludvig told me that: > Hi all, > I have problems debugging the attached code (real.f) on AMD64 platform. > However the problem doesn't seem to be AMD64-related, but Dwarf2-related > instead and it only happens if it is compiled by the PGI fortran > compiler (beta is available for free download at www.pgroup.com/AMD64). > > Debugging the 'real' binary on AMD64/Linux systems leads to GDB internal > error: > > $ ../gdb real > GNU gdb 2003-07-08-cvs > Copyright 2003 Free Software Foundation, Inc. > [...] > This GDB was configured as "x86_64-unknown-linux-gnu"... > (gdb) b hurdgy > Breakpoint 1 at 0x4000113c: file real.f, line 8. > (gdb) r > Starting program: /tmp/gdbbuild/gdb/fortran/real > > Breakpoint 1, hurdgy (xx= > /ttt/64/gdb-head/gdb/utils.c:1058: internal-error: virtual memory > exhausted: can't allocate 4294967404 bytes. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) y > > /ttt/64/gdb-head/gdb/utils.c:1058: internal-error: virtual memory > exhausted: can't allocate 4294967404 bytes. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Create a core file of GDB? (y or n) n > $ > > Something is wrong in parsing the Dwarf2 .debug_info section - > unfortunately I don't understand the GDB internals in this field. > Could someone help me with it, please? > > All relevant files (source, asm, binaries, cores) are available at: > http://tmp.logix.cz/amd/fortran/ > > Thanks in advance for any help! > > Michal Ludvig > > > ------------------------------------------------------------------------ > > real flat(10) > call hurdgy(flat, 10) > > end > > subroutine hurdgy(xx,i) > integer i > real xx(i) > end