idb bounds error

[dan0112]

Hi

I searched the forum extensively but to my surprise found nothing on the topic, so here it comes.

I am using Fortran Composer XE with the latest update (composerxe-2011.3.174). In IDB , in the Locals view, I get the following very strange behavior:

I have a type with a multidimensional allocatable array component. When I want to look at the values of elements by 'opening' the arrows to go through the dimensions, I get the following error:

Bounds error for dimension 4: index 2 is outside of bounds [1,1].
Bounds error for dimension 4: index 3 is outside of bounds [1,1].
Bounds error for dimension 4: index 4 is outside of bounds [1,1].
... etc

This does not happen if the array has only one dimension. Also, I don't get any related errors during compilation or runtime even when compiling with -g -O0 -warn all -check all.

To be more specific, I attach some sample code below. If I set a breakpoint where indicated, and then in the Locals view open the variable "policies", I am told it has type REAL(8) (40,4,55). Shouldn't it say (40,4,55,1,1)? If I then open policies%apgrid, I see 55 elements instead of 1 and am given the above error 54 times. If I open the next first element I get again 55 elements instead of 1 and the same 54 errors a second time, but in addition, now the Value column shows the same hex-number for all elements. Digging deeper, things are fine: I get 55 elements, then 4, then 40, no more errors.

To repeat myself, this does not happen if the type is defined with a component that has an allocatable array of dimension 1 only.

My feeling is that this is not a coding error, but an issue with the debugger? Anything known / any workaround?

Thanks a lot

Daniel
-------------- reduced form example follows -------------------

module mod_types
use kinds, only: dp ! integer for double precision kind value
implicit none

type tPolicies
real(dp), allocatable, dimension(:,:,:,:,:) :: apgrid
end type tPolicies

contains

pure subroutine allocate_policies(p,nk,nmu)
use mod_params, only: nx, nz, nj ! integers, can have different kinds
type(tPolicies), intent(inout) :: p
integer, intent(in) :: nk,nmu
if (allocated(p%apgrid)) deallocate(p%apgrid)
if (allocated(p%xgrid)) deallocate(p%xgrid)
if (allocated(p%kappa)) deallocate(p%kappa)
allocate(p%apgrid(nx,nz,nj,nk,nmu),p%kappa(nx,nz,nj,nk,nmu),p%xgrid(nx,nz,nj,nk,nmu))
end subroutine allocate_policies

end module mod_types

program example
use mod_kinds
use mod_types
implicit none
type(tPolicies) :: policies
call allocate_policies(policies,1,1)
print*, 'put breakpoint here'
end program example

[mecej4]

Please post an example code that can be compiled and run. The above code cannot be compiled because tPolicies does not have components xgrid and kappa. We also need the source code for module 'kinds' and 'mod_params'.

[dan0112]

Sorry, tried to keep it simple and of course failed...
Please find attached the 4 files you need.
It compiles and runs and if you use IDB you will see the bounds errrors.
This example is actually more complicated than necessary, but I wanted to stick to my original description. To recreate the problem in a much more simple way, you only need the allocatable array to be 2-dimensional, and you don't need mod_params and mod_kinds, I think.

[mecej4]

Sorry, it took me a while to figure out what was happening. In the course of doing that, I created a simpler example in one file, similar to yours. Here is the source code:

[fortran]module pars
integer, parameter :: nx=2, ny=3, ni=3
end module pars

module typemod
type tPol
   real, allocatable :: x3d(:,:,:)
end type tPol
contains 
pure subroutine alloc_pol(p)
  use pars
  type(tPol), intent(in out) :: p
  if(allocated(p%x3d))deallocate(p%x3d)
  allocate(p%x3d(nx,ny,ni))
end subroutine alloc_pol
end module typemod

program main
       use typemod
       use pars
       implicit none
       integer i,j,k
       type(tPol)   :: pol

       call alloc_pol(pol)
       do i=1,nx
          do j=1,ny
             do k=1,ni
                pol%x3d(i,j,k) = i*10000+j*100+k
             end do
           end do
       end do
       print*, 'put breakpoint here'

end program main
[/fortran]

When this is compiled with the 12.0.3 X64 compiler on Linux and run in IDB 11.1, with a breakpoint at the "print *" line. the display of the array component x3d is as follows

[bash]pol = type tpol    
   x3d =  array    
      (1,1,1)   10101
      (2,1,1)   20101
      (1,2,1)   10201
      (2,2,1)   20201
      (1,3,1)   10301
      (2,3,1)   20301
      (1,1,2)   10102
      (2,1,2)   20102
      (1,2,2)   10202
      (2,2,2)   20202
      (1,3,2)   10302
      (2,3,2)   20302
      (1,1,3)   10103
      (2,1,3)   20103
      (1,2,3)   10203
      (2,2,3)   20203
      (1,3,3)   10303
      (2,3,3)   20303
[/bash]

As you can see, the subscripts are displayed as ordered triplets, in natural Fortran array order (imagine the zeros replaced by commas).

The same a.out, run under the 12.0.3 debugger, has a significantly different and, to me, unnatural, format and you have to click on zillions of triangles just to see the values:

[bash]pol   {x3d=(...)}   type tpol
 x3d   0x6ad060     REAL(4) (2,3,3)
   (1)   0x6ad060     REAL(4) (2,3)
      (1)   0x6ad060     REAL(4) (2)
         (1)   10101   REAL(4)
         (2)   20101   REAL(4)
      (2)   0x6ad068     REAL(4) (2)
      (3)   0x6ad070     REAL(4) (2)
   (2)   0x6ad078     REAL(4) (2,3)
      (1)   0x6ad078     REAL(4) (2)
          (1)   10102   REAL(4)
          (2)   20102   REAL(4)
      (2)   0x6ad080     REAL(4) (2)
      (3)   0x6ad088     REAL(4) (2)
         (1)   10302   REAL(4)
         (2)   20302   REAL(4)
      (3)   0x6ad090     REAL(4) (2,3)
[/bash]

The subscripts are shown in reverse order! For example, element x3d(1,3,2) is displayed as

(2)
(3)
(1) 10302 REAL(4)

We badly need an option in the debugger to revert to the old way of displaying multidimensional arrays.

Finally, as you noted, the display of arrays with more than three dimensions is completely botched up and even gives false warnings of illegal subscript values.

[dan0112]

I think even with a 2D-array you can get the (incorrect) error messages, if you set one dimension to size 1. I.e. in your example, remove the third dimension and let nx = 1, then click through the derived type variable in IDB.

I agree that the first layout is much clearer than the second, and although the second gives more information, my guess is that the standard use case would be that the user just wants to see the values of the elements and doesnt need the rest (type, kind, address).

Is there any way to stay informed on this bug, so as to find out in which version / update it is resolved?

Thanks!

[Ron_Green]

Dan,

Let me get a bug report started. As for tracking this, note that at the top of this thread is a little checkbox next to "Subscribe to this thread". This will send you email when this thread is updated.

ron

[dan0112]

Ron,

thanks, yes, I already subscribed to this thread. I was rather wondering whether I could follow/subscribe to the bug report so that I'd know in which update this is resolved.

Dan

[Ron_Green]

DPD200168694 is the bug ID.

For tracking: our bug database is not exposed on the web. This thread is cross-referenced to the bug. Thus, when the bug changes state, I get notified repeatedly to update you/this thread.

If you have a valid support license, you can open a Premier issue, copy the number here, and I can tag that Premier issue with this bug ID also. Same thing there, though, the engineer that owns your Premier issue needs to update you when the internal database record changes state.

ron

[Ron_Green]

This bug is addressed in the latest IDB in Update 7.

ron

[dan0112]

Thanks for the notice! That's great news, I am looking forward to it and will let you know if I find any problems.

Cheers

Daniel