Bug 9395 - cannot access allocatable array in fortran90
Summary: cannot access allocatable array in fortran90
Status: UNCONFIRMED
Alias: None
Product: gdb
Classification: Unclassified
Component: fortran (show other bugs)
Version: unknown
: P1 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks: 11744
  Show dependency treegraph
 
Reported: 2007-07-26 09:28 UTC by virginie.trinite
Modified: 2016-04-26 13:41 UTC (History)
10 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
fortran program with 3d-array (177 bytes, application/octet-stream)
2011-02-16 16:51 UTC, Joachim Protze
Details
fortran program with bigger 3d-array (202 bytes, application/octet-stream)
2011-02-25 13:59 UTC, Joachim Protze
Details
simple allocatable array (114 bytes, application/octet-stream)
2013-02-20 17:39 UTC, Mark Schneider
Details

Note You need to log in before you can comment on or make changes to this bug.
Description virginie.trinite 2007-07-26 09:28:01 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)
Comment 1 Jan Kratochvil 2008-12-23 19:43:31 UTC
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.
Comment 2 mhp77 2009-07-15 09:00:37 UTC
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 = ()
Comment 3 Jan Kratochvil 2009-10-02 13:23:38 UTC
You need to checkout the branch:
git checkout -tb archer-jankratochvil-vla origin/archer-jankratochvil-vla
Comment 4 mhp77 2010-01-11 13:10:21 UTC
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!
Comment 5 Joachim Protze 2011-02-16 16:51:11 UTC
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
Comment 6 Jan Kratochvil 2011-02-18 00:01:51 UTC
Many thanks for the bugreport.
archer-jankratochvil-vla commit 678cbb7340d8edfa92ce6de931d8d4e9c3b86c06 should have it fixed.
Comment 7 Joachim Protze 2011-02-25 13:59:14 UTC
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.
Comment 8 Jan Kratochvil 2011-02-25 18:13:48 UTC
(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.
Comment 9 Fred Krogh 2011-08-06 19:18:00 UTC
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
Comment 10 Fred Krogh 2012-02-17 16:56:29 UTC
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.
Comment 11 Mark Schneider 2013-02-20 16:49:11 UTC
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.
Comment 12 Fred Krogh 2013-02-20 17:17:32 UTC
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.
Comment 13 Mark Schneider 2013-02-20 17:39:05 UTC
Created attachment 6883 [details]
simple allocatable array
Comment 14 Jan Kratochvil 2013-02-20 17:42:13 UTC
plan: VLA (Variable Length Arrays) and Fortran dynamic types
http://sourceware.org/ml/gdb/2012-11/msg00094.html
Comment 15 Mark Schneider 2013-02-20 17:46:22 UTC
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.
Comment 16 Marcial 2013-06-11 07:06:57 UTC
Does not work either on gdb7.4 as x86_64-apple-darwin10.8.0 but! 

Steven Vancoillie has found a way around this that may be useful. He explains in his blog:     http://numericalnoob.blogspot.mx/2012/08/fortran-allocatable-arrays-and-pointers.html   

he basically does this:

real, allocatable :: variableName(:)
allocate(variableName(4))
variableName = (/1,2,3,4/)
...
(gdb) p *((real*) variableName)@4
$1 = (1,2,3,4)

(gdb) p *((real*) variableName + 2)
$2 = 3
Comment 17 sagovic 2013-10-26 09:12:53 UTC
(In reply to Jan Kratochvil from comment #14)
> plan: VLA (Variable Length Arrays) and Fortran dynamic types
> http://sourceware.org/ml/gdb/2012-11/msg00094.html
Based on Jans plan we implemented variable length arrays for c99 and Fortran. It is based on HEAD and tested with gcc/gfortran as well as some other C and Fortran compilers.
Sources and documentation can be found here http://intel-gdb.github.io/

We are currently upreaming c99 vla support for gdb. https://sourceware.org/ml/gdb-patches/2013-10/msg00632.html
Comment 18 Jackie Rosen 2014-02-16 17:46:51 UTC Comment hidden (spam)
Comment 19 dharenberg 2014-05-21 08:41:51 UTC
Workaround/ partial solution

I had the same problem with this version:
$ gdb -version
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04

But not with the version that came with the intel compiler:
$ gdb-ia -version
No symbol table is loaded.  Use the "file" command.
GNU gdb (GDB) 7.5-1.0.160

However, in both versions, when the allocatable array is a component of a derived type, then the problem essentially reappears. An easy workaround for this case is to use the ASSOCIATE construct:
associate(my_array => this%allocatable_array)

Then I can see the contents of my_array, but not of this%allocatable_array.

I am a beginner, so I do all this in Eclipse, where it works by setting the Debugger to gdb-ia in the launch configuration properties (given that you have the Intel compiler installed). 

I guess this partially confirms comment 17 by sagovic.
Comment 20 Bernhard Heckel 2016-04-26 12:03:39 UTC
Works for me: GDB 7.11, Gfortran 4.8.3, Red Hat 7.1

26	end program ex
(gdb) p tab
$1 = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
(gdb) p tab2
$2 = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
(gdb) p tab(2)
$3 = 2
(gdb) p tab2(2)
$4 = 2
(gdb)
Comment 21 Fred Krogh 2016-04-26 13:41:00 UTC
Just tried the code in https://sourceware.org/bugzilla/show_bug.cgi?id=9395#c9 using GNU Fortran (Gentoo 5.3.0 p1.0, pie-0.6.5) 5.3.0 and GNU gdb (Gentoo 7.11 vanilla) 7.11.  It works just fine for me now.