Bug 465983 - internal error in gdb 6.8 printing pointer to an array passed as a parameter in fortran
internal error in gdb 6.8 printing pointer to an array passed as a parameter ...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gdb (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jan Kratochvil
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-07 11:45 EDT by Alan Matsuoka
Modified: 2010-10-23 01:02 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-09 17:39:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dwarf-array.f90 (564 bytes, application/octet-stream)
2008-10-07 11:45 EDT, Alan Matsuoka
no flags Details
stack trace from crashed gdb (3.81 KB, application/octet-stream)
2008-10-07 11:46 EDT, Alan Matsuoka
no flags Details
dwarf-array6.f90 (779 bytes, application/octet-stream)
2008-10-07 11:46 EDT, Alan Matsuoka
no flags Details

  None (edit)
Description Alan Matsuoka 2008-10-07 11:45:18 EDT
Created attachment 319656 [details]
dwarf-array.f90

Description of problem:

Date problem reported: 9-25-08

Problem: internal error in gdb 6.8 printing pointer to an array passed as a parameter in fortran

Argument is that even if the DWARF data is wrong it shouldn't cause an internal error in the debugger.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

  **NOTE:  This was reproduced with the ***gcc-4.1 and gdb-6.8 slated for RHEL5.3***.  LLNL has been given early access to these packages so they can try and work out any kinks that may arise.

1)
[root@dhcp243-202 ~]# rpm -q gcc-gfortran
gcc-gfortran-4.1.2-44.el5
[root@dhcp243-202 ~]# rpm -q gdb

2)
gdb ./dwarf-array
GNU gdb Fedora (6.8-23.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(gdb) b 27
Breakpoint 1 at 0x400c53: file dwarf-array.f90, line 27.
(gdb) r
Starting program: /root/dwarf-array

Breakpoint 1, MAIN__ () at dwarf-array.f90:27
27         call sub_test(yzap,yzap(:,2),2)
Current language:  auto; currently fortran
(gdb) p yzap
$1 = (( 1, 2) ( 3, 4) )
(gdb) b 9
Breakpoint 2 at 0x4009f9: file dwarf-array.f90, line 9. (2 locations)


(gdb) c
Continuing.

Breakpoint 2, sub_test_ (a_sub=
../../gdb/utils.c:910: internal-error: virtual memory exhausted: can't allocate 2372490840 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
../../gdb/utils.c:910: internal-error: virtual memory exhausted: can't allocate 2372490840 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
a_sub
b_sub
[root@dhcp243-202 ~]#  c_sub   3.000000       4.000000

What is expected from Engineering: Even if the DWARF data is wrong, it shouldn't cause an internal error in the debugger.  Can we look into getting this fixed?

Thanks!
see attached stack trace from crashed gdb.

Actual results:


Expected results:

gdb shouldn't crash

Additional info:

after looking at jakubs comments for https://bugzilla.redhat.com/show_bug.cgi?id=465291 I changed dwarf-array.f90 as he recommended and got
this.

gdb dwarf-array6
GNU gdb Fedora (6.8-23.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(gdb) br sub_test
Breakpoint 1 at 0x40086c: file dwarf-array6.f90, line 2.
(gdb) run
Starting program: /root/Desktop/RHEL53/dwarf-array6

Breakpoint 1, sub_test (a_sub=(( 1, 2) ( 3, 4) ), c_sub=(<assumed size array> 0), c_size=2)
   at dwarf-array6.f90:2
2       subroutine sub_test(a_sub,c_sub,c_size)
Current language:  auto; currently fortran
(gdb) bt
#0  sub_test (a_sub=(( 1, 2) ( 3, 4) ), c_sub=(<assumed size array> 0), c_size=2)
   at dwarf-array6.f90:2
#1  0x0000000000400d78 in test_pass () at dwarf-array6.f90:36
#2  0x0000000000400dec in main ()
#3  0x000000356da1d8b4 in __libc_start_main () from /lib64/libc.so.6
#4  0x0000000000400789 in _start ()
(gdb) f 2
#2  0x0000000000400dec in main ()
(gdb) l
1
2       subroutine sub_test(a_sub,c_sub,c_size)
3          real,target  :: a_sub(:,:)
4          integer      :: c_size
5          real         :: c_sub(c_size,c_size/2)
6
7          real,pointer :: b_sub(:,:)
8
9          b_sub => a_sub
10         call contained_sub
(gdb) f 1
#1  0x0000000000400d78 in test_pass () at dwarf-array6.f90:36
36         call sub_test(yzap,yzap(:,2),2)
(gdb) p yzap
$1 = (( 1, 2) ( 3, 4) )
(gdb)
Comment 1 Alan Matsuoka 2008-10-07 11:46:16 EDT
Created attachment 319657 [details]
stack trace from crashed gdb
Comment 2 Alan Matsuoka 2008-10-07 11:46:52 EDT
Created attachment 319658 [details]
dwarf-array6.f90
Comment 3 Jan Kratochvil 2008-10-07 16:11:31 EDT
I do not see it as a problem.  As DWARF is broken it reports garbage as the low/high bounds and GDB blindly tries to allocate such large memory area to copy the variable contents from the inferior.

We could change this Bug into a FEAT request to make GDB being able to cope with memory objects larger than its permitted address space.  But this feature is already present there - just type twice `n' and GDB will recover correctly.

Limiting the maximum object size is also not too feasible nowadays - these sizes can be only around 2GB due to the incorrect 32-bit counting of everything in DWARF and GDB itself and valid memory objects with excessive sizes are common nowadays with the multiGB memory Enterprise machines+applications.

Is `type twice n' the correct resolution of this Bug?

Note You need to log in before you can comment on or make changes to this bug.