Dwarf2-related Internal error

Dwarf2-related Internal error

[Michal Ludvig]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

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
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz

[-- Attachment #2: real.f --]
[-- Type: text/plain, Size: 133 bytes --]

      real flat(10)
      call hurdgy(flat, 10)

      end

      subroutine hurdgy(xx,i)
      integer i
      real xx(i)
      end

Re: Dwarf2-related Internal error

[Michal Ludvig]

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

Re: Dwarf2-related Internal error

[Elena Zannoni]

Michal Ludvig writes:
 > 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

I don't have much time to devote to this, but usually that kind of
error is generated by some infinite loop that gdb got itself into.
Does the same happen for 386? Maybe comparing the two would help. If
the problem is in generic code you should see the error there too.  If
not, step the two side by side and see if the x86-64 does something
weird.

elena



 > 
 > 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

Re: Dwarf2-related Internal error

[Michal Ludvig]

Elena Zannoni told me that:
> Michal Ludvig writes:
>  > 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
> 
> I don't have much time to devote to this, but usually that kind of
> error is generated by some infinite loop that gdb got itself into.

Unlikely. The immediate problem is that the size of function's parameter 
'xx' is too big:

(top-gdb) f
#0  read_var_value (var=0x8b35c0, frame=0x85ad98)
     at ../../gdb-head/gdb/findvar.c:397
397       struct type *type = SYMBOL_TYPE (var);
(top-gdb) p *var->type
$2 = {pointer_type = 0x0, reference_type = 0x0, chain = 0x89fc00,
   instance_flags = 0, length = 4294967292, main_type = 0x89fc28}
(top-gdb) p (int)4294967292
$3 = -4
(top-gdb)

Very likely it was ment to be -4 because something somewhere in the 
debug info was wrongly interpreted.

 From what is this length computed and where? Somewhere in dwarf2read.c?

> Does the same happen for 386? Maybe comparing the two would help. 

Unfortunately i386 generates completely different code and debug info 
(it apparently doesn't use dwarf2 - maybe dwarf1? Sections .debug, 
.lines, ...) that couldn't be reasonably compared. I wasn't able to 
convince it to produce dwarf2 :-(

Thanks for the reply anyway :-)

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz

Re: Dwarf2-related Internal error

[Michal Ludvig]

Michal Ludvig told me that:
> Elena Zannoni told me that:
> 
>> I don't have much time to devote to this, but usually that kind of
>> error is generated by some infinite loop that gdb got itself into.
> 
> 
> Unlikely. The immediate problem is that the size of function's parameter 
> 'xx' is too big:
> 
> (top-gdb) f
> #0  read_var_value (var=0x8b35c0, frame=0x85ad98)
>     at ../../gdb-head/gdb/findvar.c:397
> 397       struct type *type = SYMBOL_TYPE (var);
> (top-gdb) p *var->type
> $2 = {pointer_type = 0x0, reference_type = 0x0, chain = 0x89fc00,
>   instance_flags = 0, length = 4294967292, main_type = 0x89fc28}
> (top-gdb) p (int)4294967292
> $3 = -4
> (top-gdb)
> 
> Very likely it was ment to be -4 because something somewhere in the 
> debug info was wrongly interpreted.

OK, I have found the problem. The type of the parameter 'xx' is an array 
with unspecified size. Lower bound is set to '1' for Fortran and since 
there is no upper bound specified, it's set to '-1' by default.

3097     else if (attr->form == DW_FORM_block1)
3098     {
3099       /* GCC encodes arrays with unspecified or dynamic length
3100          with a DW_FORM_block1 attribute.
3101          FIXME: GDB does not yet know how to handle dynamic
3102          arrays properly, treat them as arrays with unspecified
3103          length for now.  */
3104       high = -1;
3105     }

Later, when the actual size of the array type is computed, it takes the 
size of the main type (real, size=4) and multiplies it by 
(high-low+1=-1) leading to -4 which is quite a big number when converted 
to unsigned.

Now how to solve it. For now I did

                      length for now.  */
                   high = -1;
+                 if (cu_language == language_fortran)
+                   high = 0;
                 }

which at least prevents GDB from crashing. IMHO it achieves the same 
behaviour as for other languages, where low=0, high=-1 and so the size 
of the array results to 0. In fortran low=1, so with high=0 the size 
will become 0 as well.

Would this be an acceptable solution? Any comments?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz