Sources Bugzilla – Bug 9395
cannot access allocatable array in fortran90
Last modified: 2013-02-20 17:46:22 UTC
[Converted from Gnats 2290] In this very simple program, you can have acces to tab2 but not to tab: program ex implicit none integer :: i real(8),allocatable :: tab(:) real(8) :: tab2(10) allocate(tab(1:10)) do i=1,10 tab(i)=real(i,8) tab2(i)=tab(i) end do end program ex I have use both g95 and gfortran when I use print tab2 every things are fine (a part that g95 sems to not be regonize as fortran, and that the first index is always zero,and not one) but if I want to acces to tab: in gfortran (gdb) p tab $2 = { 0x1b7a8460, -1, 537, ({ 1, 1, 10})} (gdb) p tab(1) Cannot perform substring on this type (gdb) p tab[1] A syntax error in expression, near `[1]'. (gdb) whatis tab type = Type array_descriptor1 PTR TO -> ( VOID ) :: data int8 :: offset int8 :: dtype Type descriptor_dimension int8 :: stride int8 :: lbound int8 :: ubound End Type descriptor_dimension (0:0) :: dim End Type array_descriptor1 (gdb) p tab%data(1) Program received signal SIGSEGV, Segmentation fault. 0x000000001b7a8460 in ?? () in g95 (gdb) p tab $1 = {offset = 0x15a39330 "P", rank = 1, esize = 8, base = 0x15a39338, info = {8, 1, 10}} (gdb) p tab(1) Invalid data type for function to be called. (gdb) p tab[1] Structure has no component named operator[]. (gdb) p tab.base[1] Attempt to dereference a generic pointer. (gdb) p tab.offset[1] $4 = 0 '\0' Release: GNU gdb Red Hat Linux (6.5-16.el5rh)
FYI the support currently exists in a 3rd party patch: http://sourceware.org/gdb/wiki/ProjectArcher http://sourceware.org/gdb/wiki/ArcherBranchManagement branch archer-jankratochvil-vla GNU Fortran (GCC) version 4.4.0 20081219 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20081219 (experimental), GMP version 4.2.2, MPFR version 2.3.2. GNU gdb Fedora (6.8-29.fc10) (gdb) p tab $1 = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) (gdb) p tab(1) $2 = 1 The patch is going to be submitted in parts for FSF GDB.
What is the current status of gdb support for dynamic Fortran arrays (allocatable, assumed-shape arrays)? I've tried to debug the test program above with: gfortran -g ... [also tried -gdwarf-2, -gdwarf-3, -ggdb] GNU Fortran (GCC) 4.5.0 20090710 (experimental) [also tried 4.4.0] GNU gdb (GDB) 6.8.50.20090707-cvs [also tried GNU gdb (GDB) 6.8.50.20081228-cvs, tar.gz from http://sourceware.org/git/gitweb.cgi?p=archer.git] The result is: (gdb) p tab $1 = ()
You need to checkout the branch: git checkout -tb archer-jankratochvil-vla origin/archer-jankratochvil-vla
Using GNU gdb (GDB) 6.8.50.20090909-cvs from the archer repository (branch archer-jankratochvil-vla) and GNU Fortran (GCC) 4.5.0 20091215 (experimental), I can debug the above test program. However, if I declare an allocatable array as a type component as follows: program test_gdb implicit none type :: a real :: b = 1.0 real, dimension( : ), allocatable :: c end type a type( a ) :: d allocate( d%c( 3 ) ) d%c = 1.0 print *, d%c end program test_gdb gdb issues the following error message when trying to print d%c: (gdb) p d%c Cannot access memory at address 0x3f800004 Interestingly, if I remove the first type component (real :: b = 1.0) gdb works correctly. Btw, when can we expect the Fortran enhancements to be included in main-line gdb? Thanks!
Created attachment 5246 [details] fortran program with 3d-array I checked out the branch and found some strange behavior regarding subarrays and at last gdb segfaulted: (gdb) b 18 Breakpoint 1 at 0x400aae: file array-segf.f90, line 18. (gdb) r Starting program: array-segf Breakpoint 1, typesubarray () at array-segf.f90:18 18 buffer=100 (gdb) p buffer $1 = (( ( 0, 1, 2, 3) ( 4, 5, 6, 7) ( 8, 9, 10, 11) ( 12, 13, 14, 15) ) ( ( 16, 17, 18, 19) ( 20, 21, 22, 23) ( 24, 25, 26, 27) ( 28, 29, 30, 31) ) ( ( 32, 33, 34, 35) ( 36, 37, 38, 39) ( 40, 41, 42, 43) ( 44, 45, 46, 47) ) ( ( 48, 49, 50, 51) ( 52, 53, 54, 55) ( 56, 57, 58, 59) ( 60, 61, 62, 63) ) ) (gdb) p buffer(:,:,0) $2 = (( 0, 1, 2, 3) ( 4, 5, 6, 7) ( 8, 9, 10, 11) ( 12, 13, 14, 15) ) (gdb) p buffer(:,:,1) $3 = (( 0, 1, 2, 3) ( 4, 5, 6, 7) ( 8, 9, 10, 11) ( 12, 13, 14, 15) ) (gdb) p buffer(:,:,4) no such vector element (gdb) p buffer(:,0,0) $4 = (0, 1, 2, 3) (gdb) p buffer(:,2,3) $5 = (0, 1, 2, 3) (gdb) p buffer(1,:,3) $6 = (0, 4, 8, 12) (gdb) p buffer(2:3,0,0) $7 = (0, 1) (gdb) p buffer(3,1,:) segfault The subarrays that are printed are choosen wrong. Size and dimension are choosen right, but all subarrays are aligned to (0,0,0). If the first dimension (last digit) is set to range, gdb always segfaults. GNU Fortran (Ubuntu 4.4.3-4ubuntu5) 4.4.3 GNU gdb (GDB) 7.2.50.20110213-cvs
Many thanks for the bugreport. archer-jankratochvil-vla commit 678cbb7340d8edfa92ce6de931d8d4e9c3b86c06 should have it fixed.
Created attachment 5266 [details] fortran program with bigger 3d-array It seems, that we now have infinite loops in some cases (for 300x300x300 array): (gdb) p buffer(10,10,:10) $1 = (3010, 93010, 183010, 273010, 363010, 453010, 543010, 633010, 723010, 813010, 903010) (gdb) p buffer(10,9:10,10) $2 = (902710, 903010) but: (gdb) p buffer(10,10,9:10) -> hangs, should just display the last two values of $1 With 200x200x200 array the last one gives correct answer.
(In reply to comment #7) > It seems, that we now have infinite loops in some cases Thanks, the code was reading some memory after the end of the array. For small arrays it makes no difference but with such a large array GDB tried to read unmapped memory pages which resulted in very ptrace reading and day it would say: Cannot access memory at address 0x7ffff0c75f58 Fixed now on archer-jankratochvil-vla by: 530ce8bb0aeeb513f566da7a7fae46d6414f8dc1 (gdb) p buffer(10,10,9:10) $1 = (813010, 903010) The VLA code needs a rewrite for merge, though. I do not find viable to fix the Comment 4 with the current codebase.
It seems I'm having this problem when using GNU gdb (Gentoo 7.2 p1) 7.2, and GNU Fortran (Gentoo 4.6.1 p1.0, pie-0.4.5) 4.6.1. Here is the program I'm running which includes comments on what gdb does. program test1 ! Gdb does not print entries in allocatable arrays integer, allocatable :: itest(:) allocate (itest(10)) do i = 1, 10 itest(i) = i end do print '("itest =", 10i3)', itest(1:10) print '("Stop gdb on this statement and look at itest")' ! p itest(1:2) says slice our of range ! p itest(1) gives 0 ! p itest(2) gives -1 stop end program test1
I just tried the program test1 that I posted in the above comment. Got the same (bad) result, but this time using GNU gdb (Gentoo 7.4 p1) 7.4, and GNU Fortran (Gentoo 4.6.2 p1.1, pie-0.4.5) 4.6.2. This bug really complicates the debugging of Fortran programs using allocatable arrays.
All IDE's based on gfortran/gdb have this problem, including Code:Blocks, Simply Frotran, NetBeans and Eclipse. It makes it almost impossible to debug newer code that depends on allocating arrays. And allocatable arrays in fortran have been around since fortran 90.
Just tried my little test1 program above with "GNU Fortran (Gentoo 4.7.2 p1.3, pie-0.5.5) 4.7.2", and "GNU gdb (Gentoo 7.5.1 p2) 7.5.1". p itest(1:2) once again gives slice out of range, but p itest(1) gives 6316032, and p itest(2) gives 0. Values output by the code are correct. The optimistic view is that any change from the previous result is some sort of progress.
Created attachment 6883 [details] simple allocatable array
plan: VLA (Variable Length Arrays) and Fortran dynamic types http://sourceware.org/ml/gdb/2012-11/msg00094.html
Using GDB 7.4, configured as "i686-pc-mingw32", Windows 7 Professional SP1 64bit, with gfortran 4.8 and Code:Blocks 12.11. When you try to look at an array that is "allocatable", you are provided with nonsense, and you don't even get the right amount of nonsense. However, if you change from allocatable to a fixed size array everything displays correctly, including size (see attached simple allocatable array example. As noted previously, every IDE I have tried that uses the gnu tools has this problem.