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)
Created attachment 319657 [details] stack trace from crashed gdb
Created attachment 319658 [details] dwarf-array6.f90
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?